I'm using the excellent BeautyTips plugin as a means of indicating validation failures to end users and I'm running into positioning problems whenever page content is dynamically added, removed, or animated.
Here's a concrete example. I have a DIV at the top of each page that’s used for confirmation/error messages. It's displayed in $(document.ready) using slideToggle(). This naturally "pushes" all subsequent html content down, throwing off the positioning/alignment of the beautytips. If I call the plug-in's built-in refresh method after slideToggle() has fired, said positioning problems are corrected. You can see the before/after screen-shots here and here.
One possible workaround would be to programmatically detect DOM changes, specifically changes to css, so that I could then loop over each beautytip and manually reload it. However, it appears that there are no native jQuery events which expose such functionality. I've seen the impressive jQuery plug-in by Rick Strahl that monitors CSS changes, but it seems based on the assumption that one knows ahead of time the specific HTML element(s) they wish to monitor. I want to monitor the entire document, since I can't be expected to know what html elements might exist on a given page that a) are going to be animated and b) would be at such a position in the document that they would "push" down the my beautytips. And I certainly don't want to have to incur the massive performance penalty of polling every block level element in the document.
I should mention that the plug-in works perfectly if I use it in its default "hover" mode in which beautytips are displayed only in response to user mouse input. Unfortunately, there is a design constraint imposed on the application that states all validation errors must be displayed after form submission without additional user interaction.
I'm sure there's a really simple/elegant fix that is completely eluding me. I could avoid all of this hassle, of course, by simply not using animation to display page content, but that seems like a high price to pay.
Related
I am looking at disadvantages of lazy-loading images, and I must be hyper-thorough because we are considering implementing loading="lazy" on many/most images in the site. The reason for that is that I believe I have a strategy that should work.
We are using the browser-native loading="lazy" attribute, since we dropped support for IE recently. Wow, I know.
We are setting all images above the fold to eager, and all images below to lazy, across the entire site.
Then we are listening for the page load event and running a script that converts every image with loading="lazy" to loading="eager" (or auto). So images below the fold will get loaded too, probably in most cases by the time the user scrolls (at least using modern internet connection speeds). The page load event fires after all eager-loaded images have completed, but may/should fire before lazy-loaded images have started, so that is our opportunity to trigger loading below the fold.
One known disadvantage is that lazy-loaded images can cause a layout shift as the user scrolls, since the browser doesn't know the dimensions until the image starts loading. Another disadvantage is that users may be annoyed by images that are not loaded by the time they scroll to the image. This solution addresses both of those problems by converting remaining lazy-loading images to eager as soon as the prioritized images are loaded, to reduce the chance of the user encountering these issues.
There is also the possibility that there may be specific cases where pieces of JavaScript are waiting for an image to load in order to do something with it, and that can sometimes block rendering. Let's treat that as a side issue. I think it's unlikely we'll encounter that in this site, and we'll fix it where it occurs.
A side note, I have also devised a script that observes elements being populated or manipulated on the DOM by external scripts, and converts any newly-added img elements to loading="lazy" (if it occurs before page load), so I am able to guarantee lazy loading on all img elements on the page, and it DOES yield Lighthouse load performance gains of several points.
I am so far not finding many serious and/or likely problems from lazy-loading every or most images on a page, given that it is handled with the strategies that I have devised.
My question is what am I missing. Could this strategy have gaps?
What other considerations do I need to think about? Because I don't want my decisions to cause problems on the site I am working on.
When internet connection is very quick, things are also loading quickly and the user might not even see the status before the images are loaded. However, things are not always so rosy, there might be too many people using the internet and occupying all the bandwidth they can with watching videos, listening to music, chatting with friends.
Your problems start arising when
the users are using too many devices
there is an internet outage during the load of your page
an image is unavailable or slow to load (a very slow third-party UI, perhaps)
Usually, if your design works well and handles these cases in a user-friendly way, then users will notice there was a wait/outage, of course, but will probably not link that to your site. Yet, if your design looks ugly during these phases, then the users will remember that there was an outage/slowness of internet and how ugly your page was.
Since this is something every developer wants to avoid, it makes sense to treat the internet as something that usually works, but always has the potentiality of being down or slow.
As a result, if you know what pictures will appear in the viewport and what pictures will be shown only when the user scrolls, then you can eager-load the pictures the user will see first. Of course, it is not always easy to know what pictures will appear in the viewport, especially if your page looks very differently on different devices. Yet, you could divide your content into two main sections:
the section that is shown even during page load
the section which will be shown only when the page load is complete
you can totally hide the second section and then there would be no visual problems.
Another way to handle this is to know in advance (on server-side) the dimensions of the pictures, hide the picture tags while they are loading and show some placeholder (some "loading" gif, for example) in the place where the pictures will appear and have a load event for all images that are hidden this way which would make sure that the "loading" placeholder will disappear and the actual image appear when the image is loaded. This would ensure that your layout's visual structure is the exact same while it does not have all the images to show yet as when all the images were fully and successfully loaded.
What you may not know if you've never used browser-native lazy loading is that it does not necessarily improve initial load size/time on shorter pages, because it still initiates loading anything closer to the viewport than 3000 pixels, even before the window load event fires. This is what is considered too eager.
Info about this issue: https://calendar.perfplanet.com/2019/native-image-lazy-loading-in-chrome-is-way-too-eager
That can make it useless against Google's Lighthouse performance metrics for shorter pages.
So we are implementing the old-fashioned non-native lazy loading where we have complete control via JavaScript. Our images are served like:
<img data-src="some-image.src" />
<noscript>
<img src="some-image.src" />
</noscript>
...And using JavaScript strategy similar to what was described in the original question here, in addition to the common technique for swapping Image.dataset.src into the Image.src property, or we many use lazySizes.
But I don't get a few things about the functionality of browser-native lazy loading. Particularly, why the browser wouldn't prioritize lazy images above the fold over lazy images below the fold, and not load any lazy image below the fold or fire the load event until everything is loaded above the fold.
And I don't get why lazy loading can't be set with CSS. It would be great if we could apply the loading attribute to sections of a page by CSS selectors alone. Instead we're forced to handle it either with JavaScript or on the server. With CSS it would be as simple as loading: lazy;.
I'm going to look into if these ideas are proposed anywhere. I may also post the code we use in the end.
I'm trying to make a window based application for web browsers. The number of windows is considerably high, so I'm storing them as HTML files (one per window) that I asynchronously retrieve from the server according to user interaction.
To add a window to the main page, I first add the link elements (CSS) of the downloaded document to its head section, and then I append the content of the body section to a certain div. When a window is closed, I just remove these elements.
This approach seems to be working nicely, but I can see that sometimes when I add a window, its elements are visible out of position with no style, and after a brief moment they are correctly painted.
I don't have a strong background in web programming, but I suspect this might be related to what it is called "browser reflow". Does it mean that it is taking too much time to repaint everything? Is it possible to just hide these "unstyled" elements until it is safe to show them?
Any guidance would be appreciated.
Some time away from the computer seems to have relaxed my mind. I was erroneously assuming that adding new link elements to the head section would load the CSS files immediately. Obviously, the browser needs to retrieve them from the server first. So, the DOM elements I'm adding don't show their style because the CSS files have not been downloaded yet. I think this is the right answer.
I'm currently experimenting with HTML5 Drag and Drop API. Now I've got several questions:
1.
Am I right, that it's not possible to connect draggable elements with drop-areas?
Example: You have 2 different kinds of elements you want to be able to drag and drop: Files and Text-Labels. Now if I give some div an DragOver-Handler and a Drop-Handler it will respond to both, files and text-labels. I'm looking for a simple possibility to only respond to a specific type of draggable items.
A connected problem is the dropEffect cursor-style: At the moment I enable all possible drop-targets in the DragStart-Handler and disable all of them in the DragEnd-Handler (with "disable" I mean, that I remove all DragOver- and Drop-Handlers). If I wouldn't do so, it'll look like if you could drop a file on an element that should only react to text-labels.
2.
The dropEffect cursor-style is a mess. In Firefox I don't get them at all, in Chrome it will give me a big "plus"-icon (even if I have removed the DragOver- and Drop-Handlers from an element)
3.
Last feature I am looking for is multi-select: Select multiple Text-Labels and then drag all of them at a time. Is this possible? My first idea was to create a new div and move all selected elements inside this div and then drag the newly created div. Seems pretty hackish and looks quite ugly ;-)
I hope you guys have some answers for me. Thanks!
I don't think that HTML5 drag and drop (and friends) are supposed to be replacements for commonly used "drag and drop" Javascript libraries (although it COULD be used instead of them in some cases). The name is misleading.
Modern operating systems include APIs that allow cross-application communication: clipboard and drag-and-drop. Both APIs are quite similar and need to be quite low-level because of specific challenges:
the data must be sent across processes, so it must be somehow serialized,
the sender must have a way way of offering the data in many formats (eg. text/plain and text/html) and the receiver the ability to pick one that it likes best,
the sender and receiver may live in different processes, so they can never find out about each other (they might even be entities coming from different platforms, GUI frameworks, programming languages etc.), the only channel of communication is the data itself,
Current HTML5 APIS, as opposed to - say - JQueryUI draggables - are not meant to give programmer strict control of the look and feel of the dragging process, but rather enable tight integration with the native, system-wide mechanisms. Which may or may not be what the programmer needs.
So to answer the questions:
you cannot "connect draggable elements with drop-areas", because your draggable elements can even come from outside the browser. But you can make an area that rejects certain types of data (which is what user expects from native drag and drop).
"div" and "multiselect" are not things that operating system understands (we don't have native multi-cliboards or multiple-text-selections). You CAN implement such functionality if you make a with inner divs that can be toggled (eg. by clicking while holding shift). When someone tries to drag the outer dive, make a transfer object that says which inner divs were selected (you could even create an image that shows them).
If the above solutions sound a bit low-level, well - that's because they are. When you develop a desktop game or tool, you do not rely on native drag and drop for moving pieces across the chessboard or moving sliders in the GUI. I think it will be the same with JavaScript. JQueryUI Draggables are not going anywhere.
Here's my problem:
I have a Flash object on my page.
The user can change views within the Flash. [Not directly relevant but possibly useful: when this happens, the Flash creates a JavaScript event.]
I'd like to create separate Disqus comment threads for each Flash view, and according to Disqus's customer support, this needs a unique URL (not just hash fragment) for each comment thread.
It's not possible to write to the URL (as opposed to the hash fragment) without reloading the page (except in newer Webkit browsers).
However, I'd really like to avoid reloading the page, and having to reload the whole Flash object, each time the user changes views. But I'd really like to offer unique Disqus threads on each Flash view.
Can anyone think of a smart way I can get round this?
Could I put the Flash in an iFrame and not reload it when the rest of the page reloaded... or is that impossible?
You could put the cart before the horse and make an AJAX call to replace your main page content elements, so long as the <iframe> is a direct child of the <body> and the main content is a sibling (not a parent) of it.
That is impossible as the iFrame is part of the loaded page. The only, but very ugly, way to implement this is using a frameset..
Why not make two iframes? One as big as your body, the other one smaller, centered, and with a higher z-index.
Then just navigate the bigger iframe and leave the rest of the page alone.
Yes, it's ugly. But ugly questions ask for ugly answers :)
I'm working on a web application where we have a modal panel/dialog popup to collect user data. The form within the panel has grown large and we've suggested splitting the form across multiple tabs, but our client has suggested adding scrollbars within the modal panel.
Are there usability issues with scrollbars within a modal panel? I believe it's a bad practice but I'd like other opinions.
Thanks,
Glen
Update:
I'll explain the scenario in more detail. We have a search page where search result items can be saved (copied into a another area of the system). Additional information can be saved with this items (e.g. additional comments, assignment to other buckets - I can't get into any more detail than that). When a user wants to save a search result item, they can check one or more items and click a save button - that's when our modal panel popups.
Originally, the users were taken to a separate page and they followed a series of pages. Our clients felt this was time consuming, so we changed the page to use a modal panel.
I'm not 100% sure using a modal panel is the best design, but that's what we have now. I welcome any other ideas.
Well, I gotta ask, if you have a modal form that's so long, shouldn't it be made into its own page?
I mean, the whole point of modal dialogues is to tell the user something he needs to know (which are usually disregarded and are annoying) or to get some information from the user that is necessary before proceeding.
You say your form is for gathering user input. If it's something the user must enter before proceeding (as in a part of a checkout flow or something like that), then I would say it's probably best to dedicate an entire page to the flow.
If it's something that's more of a "log in here before proceeding with what you're doing" kind of thing, again, I think it would make more sense for it to be its own page that brings you back to the page you were on before you entered it once you're done filling out the form. That's how the Stack Overflow human-verification page works.
If it's something annoying like "give us your feedback about the site", then it shouldn't be modal at all but rather an easily-dismissed (dare I say it?) pop-up window.
Modal dialogues really should be kept as brief as possible. If brevity is impossible, and the dialogue really must be modal, then I think it would make more sense to create a flow of pages that must be filled in before the next one can be accessed. Like a checkout: you need to add products to a cart before adding shipping information, and you need shipping information before you can determine the cost of the shipment. That kind of thing.
But without knowing the exact nature of your modal dialogue I can't tell you exactly which way would be best.
EDIT: Aha! Your clients felt this was time consuming, eh? This is the type of situation where you should do a very quick and dirty live usability test to see which way is actually better. Grab some people from down the hall, show some of them the modal way (with scrolling) of doing it and show others the old (non-modal) way of doing it and see what they have to say.
(Ideally you are recording the session and the screen, and you make sure to not let your own personal preferences show through. Just ask them to use the system while you watch to see how well they perform the task. Use the recording to time both methods to see if one way really is faster than the other.)
You shouldn't ever make a usability decision that goes against the norm (the norm in this case being "large forms merit their own pages") without making sure that it actually is more usable the abnormal way. When it comes to usability, the norm is usually the norm because it's usable (but not always, which is why you must test). If the client fights back, you'll at least have evidence that they're going against hard empirical evidence that what they want is silly.
Ultimately, though, the clients are the ones paying the bills. If you can't get them to see reason then you'll have to make the most of what they tell you. If the form must be in a modal dialogue, then you can at least try to hide non-essential fields under the fold (if there are non-essential fields) so that the majority of users will never have to scroll.
Make sure the buttons to submit the form (or whatever it is that you need to do with the form) are visible no matter where the user has scrolled. A really bad idea would be to put all the required fields at the top and then force the user to scroll down anyway to hit the submit button. That's just rude.
It seems to make sense to put a modal window here--I assume you're doing it as a layer on the page. But what it sounds like is that it's getting crowded, and you're looking at ways to manage the ever-increasing array of UI elements.
To answer your initial question about scrollbars, no, they are not verboten. However, as another responded asserted, you should never design action UI elements within the scrolling area.
It sounds as if some good user research could be useful here. What items are important to users. Which items are required and which are optional? Can they be categorized?
Some people suggest that tabs are useful for categorization when the number of UI items overflows a dialog box. In this case, though, I think this would be a bad idea. This isn't a setting category of dialog box, but more of a confirmation/selection/entry dialog where users will save whatever is entered and chosen. There's a good chance with tabs that users would miss the tabs and miss entering information. And if something on a "back" tab is required and a user doesn't go there, then you have a really poor error experience.
One of the things about scrolling is that it is easy for users with mice. they have the option of either clicking on the scrollbar or (for many) rolling a scroll wheel.
One thing you may not have considered, especially if some things that users can enter or choose are optional, is to create sections within the dialog box that can be collapsed and expanded. Sections with required elements would be expanded by default and sections with optional elements would be collapsed by default. If expansion of a section adds a scrollbar, that addition to the UI is obvious to users.
Of course, you may have to figure out how all this would work for people who have only keyboards, who have disabilities, and who might be accessing this on a mobile device.
I don’t think a tabbed panel is fundamentally better or worse than a scrolling panel. Each has advantages in different situations. However more important in your case is this: If you need tabs or scrolling then your panel is probably too complex to be modal. The more information input in a modal panel, the more likely a user will need to go somewhere else to get an answer, and the more work you throw away if the user decides they must go somewhere else for any reason.
The solution is to move as much information as you can out of the panel and onto the parent page/window. Let users enter the “additional information” right onto the search results page, allowing them to explore the results to help them decide on the information. Since the additional information apparently consumes a lot of space, make its controls show-able and hide-able, but always preserve user inputs between hides and shows. I think it’s okay to either tabs or scrolling to keep the footprint small. Additional information about a single search result should go in controls next to that search result, rather than in a separate panel.
The modal Save panel should only include a few controls that are instrumental to saving, such as the filename and location, and maybe the file type. If all the information is instrumental to saving, then make the save panel modeless. Who says you can’t?
Putting all the save information on another page is not much better than a modal panel, since that is also effectively modal, in the sense that the users can’t go somewhere else without losing their input. Even if you take steps to preserve users’ inputs to the page if they go to another page, most web-abused users will think they might lose their input, so they won’t try.