I like the idea of reducing the information - unless you want it. IMHO A lot of endusers don't care about the read/write buffer etc.
This also promotes standardisation of 'progress boxes' - in terms of style. Perhaps a 'pin' button could be in top left hand corner to keep the 'box' open after the 'task' finishes. Perhaps the system could 'learn' what information you want...
What are tabs and why have they been so successful? Because they crudely group 'windows' or 'sites' by the task of web-browsing......and allow the user to fine-tune this grouping by having many different real windows, each with their own tabs. The user defines the task, how the user wants to group them is up to him...
Take Konqueror, however. Konqueror is could become a totally be-all end-all solution.. Why is that a bad idea (in the current design)... Because you might end up with the *real* menu down in the top (konqueror tabs) and nothing down the bottom. Or if the user wants to fine-tune it, different instances of konqueror. Which is like a few virtual desktops.
Returning to the point, though. The above is an example of at what point crude grouping is OK and at what point it is not (IMHO)
I think that this grouping is too broad.
And that this kind of 'tasks' thing should be a bit closer to the endusers goals...at first. We are all endusers in some respect...
(from http://plasma.kde.org/wiki/index.php/Enduser)
- Get productive fast
- Learn as little as possible to achieve a goal
- Ask an intelligent person what to do as soon as they get stuck
- Know as little as possible about inner workings of system
- An interface with consistency
- No surprises
- Not to read manuals or helptext prior to failure
- Unlimited undo of everything to be able to try out without fear
- Nice personal touch of interface (like mobile phone shells)
By closer to the enduser, I mean more related to the end-users goals. Something like:
Specify Goals - Specify percentage
Specify time taking task going towards goals proportion of goal
The system should be able to interact with the task program and the recorded user patterns to make a fairly accurate decision...
If there is none, then you just put everything like the mockup...
Where to put them? IMHO (draft idea), have these progress bars 'on' the windows. Either in the task bar, or attached to them somehow. Subtle.
Tasks as I specified above, should go in a tasks area...tasks program. Which could have an applet.
I like the idea of putting download info in konqueror.
Nicholas
On 01/06/06, Manik Chand <[EMAIL PROTECTED]
> wrote:
Hi,
Chi Shang Cheng wrote:
Grouping all progress dialogs in one panel doesn't make sense.If the parent dialog is broken it is a sure negative. If you need a positive benefit then just putting an extra progressbar as a status indicator would be just fine. The More should be removed altogether or pointed to the parent so that the parent foregrounds if not already.
I beg to differ. Time taking processes have one thing in common; they ask the user to wait and watch. This drag is really more than any other relationship. No No, it is not technical, it is purely humane and philosophical.When place several items together, Gestalt psychology states that people will tend to perceive these items as related. However, placing all progress dialogs (or similar dialogs) in one central place has no meaning for the user, since all those items in that place share no semantic relationship. ........but a technical relationship ............
Very correct.Shrinking a whole window into a tiny menu item, means you'll be losing space that you could use to present information to the user.
Possibly except for single file downloads other dialogs does not fall into the category of shrinkables.Besides this disadvantage, it does has an advantage: shrinking such a window will force the developer to eliminate all unessential information, which will result in a much more clean interface.
The disadvantages clearly outweigh the advantages (if there are any), so from a usabilty perspective, this idea will probably not be much of an improvement. If user testing would show that this idea improves an aspect of usability (such as workflow efficiency or learnability), then I'll be convinced.Breaking dialogs to menu items probably would never work out in reality. However a single status docker to list ongoing processes may be useful when time-taking processes like ftp, disc burning, etc go on concurrently.
This would break up the system tray of course! It would look decent on a drop-down style but those who do have their panels at the bottom edge would possibly never enjoy using this. It puts one idea straight, grouping of time-taking process info. But to break parent dialogs is definitely a No No.
Manik
Yahoo! India Answers: Share what you know. Learn something new Click here
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
_______________________________________________
Appeal mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/appeal
_______________________________________________ Appeal mailing list [email protected] https://mail.kde.org/mailman/listinfo/appeal
