On Nov 28, 2008, at 11:50 AM, Guillaume Lerouge wrote: > Hi, > > I'm non-binding +1 for 4) . > > I think the 2 most important reasons why I like it better are: > > * Easy to use: users are guided throughout the process, one action > at a time > > 2 steps do not seem excessive to me, it's still gonnna be real quick > and it > adapts well to the various use cases we are faced with (insert link, > insert > image etc). It has both the benefits from the wizard and the > treeview. I > think it is a great middle ground between our various proposals.
You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks. Re the guided stuff just one comment: users just need to be guided on their first usage of it. Thereafter all they need is productivity. > * The dialog size is fixed, action buttons are always at the same > position > on screen This would work too with option 3. The action button would always be at the same position. The second/right screen is not about action buttons, it's about choosing options. > => this one is specifically important to me. 480*480 is a good > medium ground > between a generic, small-footprint dialog box size that can be used > for most > purposes (from a treeview to a file upload) and it would fit well on > an > EEEpc 900's screen (which is probably the lowest common denominator > in terms > of screen resolutions we should be able to support: 1024*600, > especially > given how ubiquitous small laptops are becoming these days). > > Having dialog boxes with a consistent look & feel (same location for > buttons) is very important since it will make user expectations much > easier > to manage => the same kind of button always located at the same > place will > greatly improve usability. Yes, no doubt about this. That's why action buttons are always placed at the bottom of dialog screens. However having fixed size dialog boxes is another matter and I don't believe in it. We should do it when we can but it really depends on the content we need to display. Forcing a second screen in a wizard fashion is not always good. It's only good *IF* the second screen is mandatory, if it's not then a drawer or tabs is a better solution. In our case at hand the second screen is optional and this is why a wizard is not a good structure. Thanks -Vincent > Guillaume > > On Fri, Nov 28, 2008 at 11:19 AM, Vincent Massol > <[EMAIL PROTECTED]> wrote: > >> >> On Nov 27, 2008, at 9:14 PM, Jean-Vincent Drean wrote: >> >>> On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <[EMAIL PROTECTED]> >>> wrote: >>>> Re the image selection: >>>> * It would be much much better to see the images before choosing >>>> them >>>> (the preview comes too late). You cannot choose an image on its >>>> name >>>> alone that's too hard. >>> >>> The only solution I see for this is to have a tooltip with a preview >>> in the treeview. >> >> Couldn't we show the images in the tree (as thumbnails)? >> >> In several wikis/CMS I've seen they use a media browser showing >> thumbnails of pictures and this looks a good way to select the >> picture >> to me. If I have to open all nodes to see the pictures below it might >> be hard to select the picture I want. It might be better to list all >> pictures found in a given space or wiki (still using a live grid so >> that performances are not penalized of course). >> >> Maybe a checkbox to switch from treeview to image browser? >> >>>> * What is the camera icon doing? Is it just an image? >>> >>> Yes. >>> >>>> * How do I enter advanced parameters for images? >>> >>> This mockup is about the wiki explorer, I've put the example of the >>> image insertion but this part is not to be taken as a proposal. >>> >>>> Apart from this it looks good to me but I still have a small >>>> preference for 3 since >>>> - as a user I prefer to see all options to understand where I'll >>>> find >>>> the feature I'm looking for >>> >>> s/user/power user/ >> >> Why do you say that? With your argument every user is dumb and would >> not be able to use a computer at all. Have you every seen a computer >> OS screen when there's only 1 button and wizards to go to the next >> step? Come on, look at your screen, and see all the buttons and >> places >> you can click (right now when typing this I can see at least 100 >> locations I can click and I'm on a Mac, reputed for being easy to >> use). Life is not just a wizard! :) >> >> I agree we should not make complex screen but there's a fine line >> between complex and useful. I even don't disagree with option 4 even >> though I don't think it's required (unless we wanted to make it work >> on mobile devices for ex but then it's a completely different skin >> that we would need and it would be pretty stupid to use a mobile >> device design on large screens since you'd loose lots of screen >> estate). >> >> Ok back to constructive comments: >> >> What about 2 buttons on the first screen: >> * Insert >> * More Options... >> >> If you click insert you're done and the image is inserted right away. >> If you click options... then we have 2 possibilities: 1) it opens a >> drawer or 2) you go to the second screen. In the drawer/second screen >> you would specify additional stuff like image size, advanced style >> parameters, etc. >> >> It's not as good as option 3 but it's close since you can skip one >> step by clicking "Insert" right away. Also "our super dumb users" >> would not see the options immediately so they would not run away :) >> >> WDYT? >> >>>> - it's one click less >>> >>> IMHO an extra click is only a problem if the user has to think where >>> to click and why to click. >>> I agree that 2 or more extra clicks are a problem but only one, with >>> the action button always at the very same place, no. >> >> I agree it's not a big deal. Still I'm unsure why we need 2 screens. >> The one argument that seems valid to me is screen estate but then I'm >> not sure it wouldn't fit (we need to have it work on 1024x768 and not >> lower since all our site is made to work on 1024x768). >> >> [snip] >> >> Thanks >> -Vincent >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Guillaume Lerouge > Product Manager - XWiki > Skype ID : wikibc > http://blog.xwiki.com/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
