Tag Info

New answers tagged

0

"Evidence" of B being right is that both Windows and OS X uses that design: Note that they both write the amount of empty space because that's what the majority of users are interested in knowing... Common progress bars works in the same way - I guess the idea is to show "What has been done/What's left to do" or "what's filled/what's empty" ratio


0

I agree that the most important information must be on the left. I also agree with @Customized, that you do not need both remaining and used, one is enough. My answer is based on the goal of the users, and according to @Mandrid : "...people like to know what they have left." The information the users need is the remaining, so option A is the best ...


0

I agree with both answer's, Also showing "10% or 90% remaining" is useless, we should keep the design as simple as we could and only provide information needed. Human brains are fast enough to process remaining % then our eyes to take an input from screen process it @brain.


0

I agree with Evan, but where in the question does it reference a storage tank? He's correct, but it depends on your usage. If you're talking about battery life, then option A is correct. However, if you're in fact talking about a storage tank, or hard drive space, then option B is correct.


4

Option B is more appropriate. Since the usage is about a "storage tank" that is "getting full", and with the Western convention of progress moving from left to right, the experience of option B is consistent with the emotional context. I'm happy to see that I have only used 10% and have much more space (i.e., progress) on the right before my storage tank ...


0

As users can begin and finish registration at different points depending on their circumstances a Wizard seems like the most practical solution. Breadcrumbs seem like a good solution but they do not provide any concept of an end point, breadcrumbs could theoretically go on forever which the user would not want. I was thinking a percentage based tracker ...


1

I believe you missed the point of progress bars. They are not intended to represent the progress of a task, they are intended to show that the task is not stuck. Windows 7 progress bars flash every so often so indicate that it is not stuck even if it is not moving. Some software gets away with showing progress with totally unrelated messages such as "Hiring ...


0

Using a progress bar to show the completion of steps is utterly wrong, IMO. I use progress bars strictly for those task that, I can predict the time/size of the task, in one single unit (e.g. seconds/megabytes). I can divide the task to progressive units, and all units have equal weight. I can calculate how much of progressive units has been completed. ...


1

Really I think Marvin did a pretty good job of answering this question already. Something I'm going to add though is that, at least in some cases, Civilization games' installers tend to show exactly which file is being installed, right down to the individual pngs. They'll include the path as part of the name of the file, and since they'll basically go ...


3

With an installation of 8-15 seconds, the user should not get the impression that the progress bar ever gets stuck (be sure to monitor the progress fine-grained enough so that processes that take more than one second or sometimes a not completely predictable amount of time - such as searching and downloading some extra files - consist of enough sub-steps to ...


1

I think it depends on how long you expect the load time to be. If you expect it will be ~10 seconds or less, most users probably will not care about details. If you expect it could be several minutes/hours, users might want more details than just a progress bar.


7

I would argue that "8~15 seconds" could in fact be long enough for an impatient user to navigate away or to think the app may have crashed. Changing messages is therefore useful as an indicator that something is happening and conveys a little more "why" of waiting than a buffering circle or similar. Whether the messages are of importance to the actual ...


7

No, they don't care about the details. But the great thing about it is that they know exactly what is happening, it feels like he/she has control.


32

As an analogy, consider the mirrors universally installed in elevators. While these mirrors give the user a false sense of added space in the lift, they also serve as just mirrors; people tend to look at themselves and do not seem to notice how long the lift is taking to take them wherever they are going. But if they put in a countdown telling people 'xx ...


1

Your half T-shirt indicator is good, still my suggestions are: easy to recall as time period between the actions could be quite large, users could forget about award when they visit the site next time, so provide description for this indicator, which is displayed as tooltip, etc. non-pushing award isn't primary functionality, so displaying "1 of 2" could ...


13

showing what the program is doing while working on a progress bar gives an additional indication of progress. There is also a nice way of doing this involving a details screen: This method doesn't just show the progress of the installation as a whole, it also shows what the current step is, what the previous steps is and sometimes even the progress of the ...


62

Showing details in a form not only developers understand is fine. If you are able to write your installation details in a more funny way than just "Checking Operating System Version" this might have two advantages: The user gets feedback about what's going on and that there's something going on at all. When installing e.g. a computer game you normally have ...


32

It can be useful for several reasons. One is that the user gets a feeling of that something is actually happening and not just a progress bar increasing. If the UI says "Checking OS Version" or "Initiating virtual processor" she gets a feeling that something good happens, even if she doesn't know the technicalities behind it. Second, if the process would ...


0

Progress bars describe a process being completed from start to finish. Even when you are undoing a previous process, the removal process has a start and a finish. It's not like you conceptually start at the end of the process and then move backwards. From a user perspective, there's still a process happening that has a starting point that comes at the ...


2

It would probably be a good extra touch to have the progress bar roll backwards. This would make it clear to your user that the changes have been completely reverted. This is a necessary distinction, because a lot of poorly-written programs DO NOT fully revert their changes, e.g. they leave loose files lingering after the revert.


0

The progress bar as it stands for the meaning that it is a progress for the action that is being performed. I repeat that it is for the 'action' progress and not 'semantic-perception' progress. A progress bar is meant to be progressing and it can revert back only if it is a continous event as in case of performing roll back of the same event in continuity. ...


1

Since many answers imply that user experience may suffer with indeterminate progress bars, or a progress which is slowing down/jumping/moving backwards, here an another approach similar to how many computer games with longer loading times solve it: Processing Level 1 Nodes... [#######----------] 35% done Simply start with "Processing level 1 Nodes" and ...


0

You can break the long task up into sub tasks and show the progress of these sub tasks, which should give the impression that things are being completed. You can provide some useful information that is not strictly related to the task at hand, so that the users feel like they are not just sitting there waiting for the process to complete, which gives the ...


2

I've seen many applications that use two progress bars. For example: one progress bar that indicates the overall progress, and the second one shows the progress of current item. This way, some items can be fast and others slow. The overal process are for example the number of subtrees at level two of your tree that are already processed. Current item might ...


2

How about making it explicitly clear that the total is still being updated and the confidence in the % value is low / subject to change? This is a modified version of the approach taken by 'WinMerge' when scanning through multiple directories (trees of nodes): **Progress** Total items: 500 (still scanning for more..) Proccessed: 100 (~20%) .. which ...


2

It seems like your app is a lot like an antivirus software. Like mentioned before, you might want to just have a text only indicator. If you're really set on a progress bar, perhaps do a marquee first to scan the tree up to a certain level to scan for the number of "main" branches, and then use that and hope that it works good enough. You could also ...


2

Here's my suggestion: you cannot know the size of the ENTIRE tree in advance. However, you do know how many objects are directly below the root, and once you scan one level deep, you also know how many objects are in the Nth object directly on the root. combining these 2 things, you might be able to use a dual progress bar setup, where you have 1 progress ...


12

How about making the length of the status bar grow as well? That way, progress goes up even when percent done goes down. [###-------] |30%| 3/10 [####----------------] |20%| 4/20 [#####---------------------] |19%| 5/26 It's easier to think about it as two status bars: "work completed" overlaying "total work." The ...


5

YES! A progressbar shows the best-available estimate of completion. Ideally it would move entirely smoothly and the progress should finish at exactly the moment it hits 100%. In reality progress estimates always suck and progress bars are jumpy. Please, for the love of life, try as hard as you can to be honest with users. Give them the best available ...


2

Without a good way of estimating, you are better off not estimating - rolling back would count as a form of bad estimate, and should be avoided - perhaps instead display the number of elements processed and a time taken, and allow the user to do the logic of "When I did this last time, it had 10k elements, this time it has 15k..."


5

Based on the additional information from the comment, the following situation seems to apply: You do not know the total number of nodes on all levels of the tree. You know the number of nodes in the tree down a given level (say, the root level). Just showing the progress within that known number of nodes down to a given level will not show enough ...


24

Are you performing a depth first traversal? When processing a node do you know how many children it has? If so then one approach is, for any given node assign equal weight to each of the children. An example: When examining the starting node we find it has two children: 100 / 2 = 50 so each of these is assigned 50% of the progress bar. When examining ...


66

If it is possible to traverse the entire tree before beginning processing, I would display an indeterminate progress bar while you discover the branches and then switch to a traditional progress bar once you know the maximum value. If you cannot identify the total size of the tree before processing, then a progress bar may not be the best option. A ...


6

In terms of the particular type of design pattern you are dealing with, I'd say that you are looking at indeterminate progress bar designs. These can be a bit tricky since they generally tend to be very basic, but if you want to provide details then they need to be accurate and not confusing to the user. My suggestion is that you can probably show the ...


2

Some research I recall on progress bars had found that if the display of progress just pauses or slows down this would be reason for user concern and their perception of elapsed time would increase. As per other answer displaying the number of units completed is positive. As is displaying number known items so far. Indicating rate of units completed per ...


3

I do think it is weird to go backward. If you just need something basic and visual, you could specify that the progress bar is only updated when it shows advancement. That may result in fast initial progress and then jumpy progress after that but many progress bars work that way anyway. You could alternatively show the two numbers (45 completed / 345 ...


2

Another alternative is using Tab, that can you enable or disabled depending of the context. In this example you enable/disable the Step 3. http://jsfiddle.net/V7GTY/2/



Top 50 recent answers are included