What are there the usability implications for a long list of items (f.e. facebook news stream) to use an internal scrolling (just the list panel) vs a full page scrolling.
Edit1: Do you have references of analysis/guidelines discussing this issue?
Depends on the composition of the page.
If the page displays other information and it is desired to keep an eye on it while scrolling that long list, then it may be preferable to use what you call "internal scrolling".
On the other hand, such scrollable parts are generally considered to be signs of a bad UI design. If you bring the argument that without scrolls the page would become huge, then you may want to reconsider the page layout and what information is really needed here together. Splitting a page into multiple specific views without scrolls might be a better idea.
From my experience multiple scrollbars on a page frustrate users, The best thing you can do is use CSS/javascript/jQuery to make items that you want to stay on the page move with the user. Slashdot's commenting system uses something similar to keep information pinned to the top of the page where it's needed. There's lots of other examples on the web, and it generally leaves a good impresssion on the user.
Related
what does Recalculate Layout Paint mean in chrome developer tool TimeLine records? and how to improve the page performance by reduce the page Recalculate,Layout and Paint's count? can give some suggestion?thanks
Basically, they're your browser figuring out how to draw the changes that you made to the page.
Don't worry about getting rid of them -- if you did that, your site would be static.
However... ...if you want to do something that IS useful for performance, which does have to do with reflows and repaints, then batch your changes together.
Lets say that you got a job at Twitter.
And your job is to write the next version of the window that adds each twitter post to the screen.
If a user gets 250 new tweets in their timeline, and you add each one in a loop, one after the other, the browser is going to slow way down, because every time you add one, it will have to reflow (move things around to make space for the thing you added) and repaint (style everything that was affected by the addition).
A better way of doing it would be to build the list of new tweets together off-DOM (ie: with elements that aren't actually on the page right now), and then add them all at once.
This cuts down on the number of times that a browser has to figure out where everything needs to go.
#Fabricio -- Micro-optimizing might not be great, but appending hundreds of browser elements in a loop, versus putting all of them in at the same time can make a big difference.
Just ask the Twitter guys, who weren't bothering to cache their jQuery objects.
Here's a very handy list of properties and methods that trigger the layout (reflow) of a page:
http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html
You want to minimize these calls as much as possible -- especially in situations where performance is critical, such as during the scroll event, or when animating large blocks of content.
You can use the "Profiles" tab and "Audits" tab to detect the performance of your code. The will give you a report about your codes.
You can reduce the page Recalculate,Layout and Paint's count by many ways.
Append many child at one time.
Hide elements before change them.
Give images and other elements height and width.
I'm experimenting with creating a metro style app with Visual Studio 2012, I am not the most experienced designer but one thing with my applications is confusing me.
I have been working with 'basic pages' instead of blank ones for the different pages in my application for design consistency, however it seems that these 'basic pages' have a strange behaviour. Every item I place on the page (buttons, text boxes, etc) will all slide in one by one when the page opens. For example if I run the application and navigate to a page with 10 buttons, it will do a brief animation where each button will slide in from the right side to the left side. When dealing with a large number of items on one page this can take a lot of time as each item slides in seperatley.
Looking at the properties for each item I have been able to change the direction it slides in while loading the page by changing the flow direction. Also with a bit of research I am thinking it could potentially be due to either the metro style 'enterPage' or 'enterContent' animations, though I can not be certain.
I have tried to experiment and figure this out, and search to find out what causes this so I can modify it (Ideally I would like to just group items together to slide in with each other) however it's kind of a difficult thing to search with vague words, so I'm asking here.
What is causing this and how might I go about modifying it?
EnterPage shouldn't be sequencing the animations. They do offset some of the animations of a number of elements, but it shouldn't be each one sequentially.
Are you using WinJS navigation?
Well after a bit of experimentation I figured out that putting all my page content inside a grid made them all come in at once like I wanted. I probably should have tried that earlier but everything was already inside an outer grid for the page, so I thought that woulda handled it.
I don't quite understand it fully, but that works for now.
I have a form with almost 60 controls on it and the client wants all that information to be fillable on one form, because all that is related to one document. Are there some usable patterns to do that? Some ways of dealing with such problem i see:
put many controls on one page with vertical/horizontal scrolling(for example i hate scrolling, dont think that decision is suitable).
create tab pages for sections. But here is a small problem: the sections are not really there, because all information is related to one thing..Tho still i can create some sections, but must save/validate all tab pages at once.
Please suggest some common practices for such problems.
Well, my app has forms with far more than that on and so I feel your pain.
I would avoid scroll bars. It's much harder for the user to be sure that they have seen everything when you have scroll bars.
I'd recommend page controls (i.e. tabs). I'm sure if you try hard enough you'll find some sort of grouping that makes sense.
The other approach you sometimes see used which is similar to a page control is pages but with Next/Back buttons. The problem with this is that it is needlessly linear.
It's harder to advise on validation. If the validation only depends on the value of the single value in question, then validate on entry. Consider using colour highlighting rather than dialog boxes. Only show hard fail dialogs when the user tries to dismiss the dialog.
Validation for values whose validity depend on other user input is harder. I'd postpone that to dialog dismiss time.
I was wondering if, whenever I have a situation in which I have to hide some UI element temporarily, it is sufficient to hide it (many frameworks give this option) or I should delete the object in memory and recreate it later when needed again (with the same parameters).
What are the pros and cons of each solution? I was thinking that maybe by hiding the element you save state informations that may be important, and you also save the allocation time, so maybe it is the better way for elements that must be hidden for a short period of time. But what if the time becomes bigger? I would then have a non-needed object in memory for the whole time.
One example, to give a clear picture of what I am talking about, would be a toolbar that changes buttons based on some context change. That is, normally there are some buttons attached to the toolbar, but when the user select one action in some other part of the interface, those buttons must be replaced by new ones (one of which is the "Done" button). Similarly, when the user selects the "Done" button in the toolbar, it goes back to the initial state.
I don't know if this is a stupid question and maybe it could be that I'm doing something like premature optimization... but I will be thankful for all your answers.
I think that the general rule of the thumb is that elements that you plan to reshow, should be hidden; otherwise destroyed (some exceptions obviously apply). When/if this becomes infeasible, you could consider further optimizations.
It's a very good question. Here's what occurs to me:
Suppose (just for the sake of argument) you have lots of different forms that could be displayed in the same space. Then if you create/destroy controls, you are only paying at any one time for the controls that the user can see. On the other hand, if you hide/show controls, you are paying all the time for the large number of controls the user isn't looking at (and may never look at). So I always create/destroy. (Actually I keep previously used controls in pools so I'm not actually re-creating them.)
Many people store user state in the controls of the UI, but personally I hate that and I never do it. I think if some information is worth remembering it belongs in application data structure. This means of course, that the controls of the current visible form have to be "bound" or kept current with the application data structure. I just make sure I can do that no matter what.
I've had to be inventive to accomplish these in a way that simplifies application code, and as a result the method I use is not well known, which exacts another kind of price.
There is no general answer to this question. It depends on the system type, CPU and RAM restrictions, the number of UI elements in question, how frequently the UI is going to be shown / recreated, etc. Perhaps if you could give an example we might be able to give you more concise feedback.
Javascript objects are not like Windows (GDI) objects: they usually don't have a will to send/receive messages - almost passive. It takes less code to hide, right?
Perhaps it depends on total amount of interactive objects per user session.
In a project I'm working on, we have a nav menu where items are colored when the relevant section has information beneath it, or faded when there's nothing available to the user. In the case of an admin, these items may have no useful information but may still be clickable (since things like "Add news item" or "Add file" are implemented as sub-menus).
The call from On High has come down to make these admin items stand apart somehow. Since we're already using the faded text for unclickable items, I was wondering if there's an established UI convention for denoting that an item is clickable, yet contains no information.
And yes, I've already asked why we're bothering to show items that aren't available to the user. The short of it: because On High wants to.
Short answer, no I don't think there's a convention for this. Lots of people would say if its not applicable, don't show it. However, there's some debate on this. One of the reasons Microsoft started using The Ribbon in MS Office is because they wanted to get away from dynamic menus where options hid and showed 'intelligently'. Users couldn't figure out the rules for what appered where, and when.
Maybe separate the concerns here: 1) how to indicate the item is clickable, and then 2) how to indicate the item contains no information.
The first one is relatively well established -- blue underlined text. You can also make it look like a button Of course, if you've got a site-specific look for your hyperlinks, use that. Basically don't break the users' expectiations of what things are clickable.
Second, how to show there's nothing there worth clicking on. I think what you want is some visual indication of the priority/utility of these admin links relatively to others. Some options:
Can you move the admin links to the bottom of a list?
Add a number indication how many things are on the other side of the link?
Strikethrough on the text?
Since there are no hard-and-fast conventions on this sort of thing, just remember that anything you do which is consistent will work. Some things will just work better than others.
No matter what you choose, the user will learn after a few tries what the new method of empty indication is.
If it is well thought out and consistent, they will probably get it after a couple of clicks.
Also, remember that too many highlights, colors, fades, and underlines will wash out any amount of effectiveness at visually organizing your menu so it is easy to use. At some point it can actually get harder to use by over-organizing things.
Think about it this way: There are two boxes sitting on a virtual shelf. One is red and the other is blue. The selected box is identified by a differing color than the other box... Now, which is the selected box?