[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ui-best-practices-working-group] June 25 p2 UI design walk-through
|
David, I couldn't agree more.
In fact, when p2 was first integrated in the SDK we knew that we had designed the UI to address some of the concerns of less technical users (users in your description #1 and #3), even though the first people actually seeing it and using it in an SDK I-Build would be more like user group #2.
We talked about these roles early on when starting out in the p2 UI, although I'm sorry to say we didn't document much on the wiki and as development continued, we had our hands full just stabilizing our very first vision of what the p2 UI might be without much time to revisit the basic assumptions. That's why I'm anxious to walkthrough now, early in the 3.5 cycle.
We liked Mary Beth Raven's approach of actually naming the users with concrete names so we could talk about users easily.
(See http://www.ibm.com/developerworks/blogs/page/marybeth?entry=meet_our_hannover_business_user).
Obviously our user set would be different than that for a product like Notes, but we specifically talked about the need for a UI that was much friendlier for someone like "Samantha."
Returning to the idea of defining and naming these users would be a good way to help communicate the tradeoffs in decision-making.
It gets quite difficult to say, "users of RCP applications who don't care about plug-ins don't want to know blah blah blah..." whereas if we worked to define a set of users we could say things like "Samantha doesn't care about feature inclusion, whereas Nick certainly does"...
The agenda for today touches a bit on this issue:
Unfolding of detail for installation contents
- Balancing the simple view with more detail for advanced users
susan
![Inactive hide details for David M Williams/Raleigh/IBM@IBMUS]()
David M Williams/Raleigh/IBM@IBMUS
![]()
| ![]()
| ![]()
To: User Interface Architecture Working Group <ui-best-practices-working-group@xxxxxxxxxxx>
cc:
Subject: Re: [ui-best-practices-working-group] June 25 p2 UI design walk-through |
>
If anyone has any other suggestions for making this walkthrough work well, please let me know.
While sort of late or a suggestion, it might still help spur discussion ...
I think one thing missing from some of the info I've seen is a description of the use-case, even users, that are being targeted.
I'm not sure there's "one UI fits all" in this case. For example, here's some quick off the cuff descriptions of what I mean ...
Casual user, moderate technical, develops applications. Wants to search for or get fairly broadly scoped functionality. They might have only the Platform installed, but now specifically want XML, or _javascript_, or Team Collaboration tools, or Modeling tools.
Technical user, developing add-on plugins, deep knowledge of Eclipse and other plugins. Wants to search for or get fairly specific plugins or features. They might have large, complex install already, but now know they need "XSD Info Set from EMF Project".
A user that just wants to update what they have installed .... they may want "the latest of everything" or they may want fixes only in a certain area (e.g. Platform, or Web Tools) without getting other fixes. Even, it'd be cool, to get a specific fix for a specific bug. Or, they may have been directed by a friend or by "service" to get the "xyz" update of a particular plugin or feature.
So ... just ideas for a starting point of documenting use-cases ... take 'em if they help, forget them if not.
| From: | Susan Franklin McCourt/Beaverton/IBM@IBMUS |
| To: | ui-best-practices-working-group@xxxxxxxxxxx |
| Date: | 06/19/2008 06:37 PM |
| Subject: | [ui-best-practices-working-group] June 25 p2 UI design walk-through |
Hello again!
In the interest of making the 6/25 walkthough as productive as possible, it would be ideal if you arrived at the call having used both the 3.3 and 3.4 Software Updates UI.
- In Eclipse 3.3, choose Help>Software Updates>
- In Eclipse 3.4 (RC4 build or later), choose Help>Software Updates...
If that is not practical for whatever reason, I've prepared a wiki page with links to screen snaps/scenarios for each UI.
http://wiki.eclipse.org/Equinox_p2_UIWG_Walkthrough
This page also lists the discussion topics I hope to follow.
If anyone has any other suggestions for making this walkthrough work well, please let me know.
See you next wednesday...
susan
----- Forwarded by Susan Franklin McCourt/Beaverton/IBM on 06/19/2008 03:28 PM -----
Hi, everyone!
I haven't participated in the UIWG before, but am interested in getting some input from you.
I've spent much of the last year working on the UI for p2, which is the provisioning system that has replaced Eclipse Update Manager.
We just finished up our work for Ganymede, and so it's time to triage bugs and prioritize for the next release.
I was hoping to be able to do a walk-through and get some ideas from you folks about how to improve the UI.
In advance I would send out some screen snaps and instructions that take you through Update Manager, what problems there were, what we tried to solve, then trying the p2 UI. Then perhaps a few discussion points surrounding problems we know we have, but mostly an informal discussion of what you think, where/how can we do better, etc.?
Ideally I could be ready for the June 25 meeting.
Would this be ok?
thanks,
Susan McCourt_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group[attachment "pic26394.gif" deleted by David M Williams/Raleigh/IBM] _______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
