Thanks Guillaume, I'm a bit rough myself so please excuse me. ;-)
2009/9/2 Guillaume Lerouge <[email protected]> > Hi Thibaut, > thanks for your feedback, we need more of it even if we sometimes welcome > it > a bit roughly :-) > > On Wed, Sep 2, 2009 at 2:17 AM, Thibaut DEVERAUX < > [email protected] > > wrote: > > > To be more precise, personas : > > > > Jo, > > Know what is a wiki. > > > > "Where is the "edit button??? Ho, at the top ! " > > > > Mike > > Don't know what is a wiki > > > > "What can I do now?" > > Mike is looking arond the page, looking fo something logical. > > Mike may not notice the edit button since he is looking near the content. > > Now iimagine Mike sees the edit button. > > (Interesting : If he scroll he will se that the bar is scrolling to so it > > may help him to notice it) > > "So there is an edit link, I gess I will edit somehing, but what?" > > Mike click on the edit button. > > It open the editor with the content of the page. > > It take a few miliseconds to mike to understand. > > "Ho ok, this is editing the content of the page." > > > > 9 lines for mike... > > > > > > If the edit button btton was near the content mike would have nticed it > > more > > easily. > > Also He would have linked it more easily with the fact it is editing the > > content. > > > > > > This is what makes the difference between the two designs... > > > I happen to agree about the fact that the page action buttons should be > located in the content area of the page. Additionally, power users can also > get accustomed to keyboard shortcuts and they're even better than the > non-moving top bar: > > 1. fingers don't need to leave the keyboard -> faster > 2. always available wherever you are on the page > > So this global discussion could go on for ages before we come to an ideal > solution :-) We'll definitely keep working on improving XWiki's UI / UX in > the coming releases (XE 2.1 is scheduled for the end of the year) and > sharing the work with the community in order to assess all options and come > to an optimal choice. Many corporate users are not familiar with wikis at > all and we'll explore all the ways to make the UI / UX easier to understand > and use for them. We'll be looking for your feedback during that time and > the 2 mails you just wrote will definitely be useful. > > Now when it comes to releasing XWiki Enterprise 2.0 with or without > colibri, > I'm definitely in favor of using Colibri. As Vincent stated it, the new > skin: > > - Doesn't have drawbacks toucan doesn't already have > - the action bar is in the same location > - all important items are in the same location -> no new UX issues (no > regressions) > - Brings a lot of improvements > - scrolling issue fixed > - ability to change colors and select a theme > - panels no longer go up to the top of the page -> allows for more > flexible layouts > - new visual identity which is an important part of XWiki Enterprise > 2.0 > - the page title is displayed automatically (we get a lot of strong > feedback from our corporate users on this and they will like it > a lot - even > though we need to fix the double title issue on a number of pages) > > So I don't see a compelling reason not to use it. You're right about the > fact that it means splitting XWiki's renovation in 2 (new look today, new > ergonomics tomorrow) but this isn't an issue by itself as long as we keep > working on improving it in the future. > > Thanks for your feedback, > > Guillaume > > > > > > > > > > 2009/9/2 Thibaut DEVERAUX <[email protected]> > > > > > Ho that's it. It is a design decision based about scrolling. I forgot > > this > > > point. > > > > > > So I understand now. Yet I still have some remarks about this because > > what > > > you choose now is not neutral at all. > > > I don't say it is good or bad. I say everybody have to understand the > > > implications. > > > > > > /***************************** > > > Disclaimer : > > > All of this is mainly theorical, UX is not an exact science when you > > can't > > > make tests. Also I can be biaised by my own eperience (I'm definitivly > > not a > > > newbee user, more probably a geek user). > > > The only manner to really be sure about it is, like usual, to make > tests > > on > > > a few real newbee users... > > > *****************************/ > > > > > > > > > Situation : > > > > > > Just imagine you are in a supermarket and you search for butter. > > > > > > First of all you assume butter is somewhere in the food aera. > > > > > > Then you may think that butter is with all prooducts based on milk. > > > > > > Also it should be in a freezer aera. > > > > > > So you will find easily the butter. > > > > > > > > > Information architecture and ergonomy use a lot a methode called "card > > > sorting" to create such logic aeras. They write the elements of the > > > interface on paper. Then they ask people to group card they think to be > > > linked. Then they make stats on groups to define an architecture of > > elements > > > grouped in a logic way. > > > > > > More information : > > > French : http://www.ergolab.net/articles/tri-cartes-ergonomie-web.php > > > English : > > > http://www.boxesandarrows.com/view/card_sorting_a_definitive_guide > > > > > > > > > You understand, I think, what I mean. In a "logic aeras" way the edit > > > button and all what is related specifically to the content on the page > > > should be near the page. (I dont mind it is moving or not, since it is > in > > > the content aera) > > > > > > > > > Ok. Now, you will say me that anyone found a solution to get at the > same > > > time the content related links near the content and at the same time > > having > > > the content related links always accessible. So : "the menu becomes > > > inaccessible once you scroll down". > > > > > > > > > This is right. So they're is a deal... > > > > > > > > > Will I choose something : > > > > > > * Efficient ? Quicly accessible user bar. > > > > > > * Newbee friendly ? Put the information where they will search it. > > > > > > > > > > > > It really depends on the targeted users : > > > > > > * If users know the should be an edit button somewhere, choose > something > > > effcient. > > > * If users will use the wiki all the days choose something efficient. > > > / > > > * If firms have a problematic of adoption and at the same time a lot of > > > people not skilled in computers choose something newbee friendly. > > > * If yo want anybody can contribute quicly, even if not at ease with > > > computers choose something newbee friendly. > > > > > > > > > For my part, not knowing who are the personas, I would have choosen the > > > version where the content related actions are in the content aera > because > > : > > > * Imo and according to what I read, scrolling back to someting he has > > > already noticed is not the greatest problem for casual users. > > > * A newbee oriented design avoid getting people lost since a regular > > users > > > design only deserve regular users confort. > > > > > > > > > Yet I guess the main clients xwiki are people who have to use regulary > > the > > > tool or people who know that they here to edit page and that it can be > > done > > > cliking on an "edit" button somewhere on the page. > > > > > > > > > So... Imo this decision is not about a blind vote in a mailing list > where > > > evryone is biaised by the fact he know the tool. This decision is to : > > > > > > * Have its implications evaluated. Best by tests, else by brainstorming > > > like we are doing. > > > * Being linked with political and marketing orientations. Project > leader, > > > marketing personas, community... I don't know who.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2009/9/1 Sergiu Dumitriu <[email protected]> > > > > > > Thibaut DEVERAUX wrote: > > >> > The skin is still the provisory skin isn't it ? > > >> > > > >> > I would prefer to wait for the nice version being programmed. > > >> > > > >> > I think the provisory version has no real advantage on the old one. > It > > >> is > > >> > the same information architecture (worst indeed) with only the > > >> minimalist > > >> > layout as a plus. > > >> > > > >> > Imo the minimalist layout is made to work with the exellent > ergonomics > > >> from > > >> > first Caty versions. This is what makes it emotionaly coherent. So I > > >> would > > >> > prefer to wait the skin being developed. > > >> > > >> Actually, one of the main reasons why the menu had been moved (at the > > >> expense of loosing permanent access to it) was to eliminate the > > >> flickering effect when scrolling. Now that a community member provided > a > > >> nice fix for this issue, it is possible that we will end up not > changing > > >> the layout in that direction after all. > > >> > > >> As Vincent said, this skin has the great advantage of being easy to > > >> change, and we need this in 2.0 . Please let us know what are the > > >> specific bad points from your perspective, what you think is worse > than > > >> in the previous skin, and what makes the proposed layout (where the > menu > > >> becomes inaccessible once you scroll down) have better ergonomics than > > >> the current one, where you have immediate access to the actions all > the > > >> time. > > >> > > >> Thanks in advance for a more detailed feedback. > > >> > > >> > > > >> > > > >> > I would propose : > > >> > > > >> > 1 - Start from the nice proposition > > >> > 2 - Work on the menu UX design, wich was the discussion point. (use > > >> > "advanced" button ?) > > >> > 3 - Develop it... > > >> > 4 - relase Colibri skin > > >> > > > >> > > > >> > So unless I missed something and the colibri skin is not still in > his > > >> old > > >> > provisory state, it will be -1 for my part. > > >> > > > >> > > > >> > > > >> > 2009/9/1 Th > > >> > omas Mortagne <[email protected]> > > >> > > > >> >> On Tue, Sep 1, 2009 at 14:29, Vincent Massol<[email protected]> > > >> wrote: > > >> >>> On Sep 1, 2009, at 2:28 PM, Guillaume Lerouge wrote: > > >> >>> > > >> >>>> Hi devs, > > >> >>>> I think we should make colibri the default skin in XE 2.0 RC1 if > we > > >> >>>> want it > > >> >>>> to be tested and ready for the release. > > >> >>>> > > >> >>>> Here's my +1 > > >> >>> +1 but only provided we agree on the default colors. Right now I'm > > -1 > > >> >>> with the current colors. I've had several negative feedbacks about > > >> >>> them (too light). > > >> >> +1 > > >> >> > > >> >>> Thanks > > >> >>> -Vincent > > >> >>> > > >> >>> _______________________________________________ > > >> >>> devs mailing list > > >> >>> [email protected] > > >> >>> http://lists.xwiki.org/mailman/listinfo/devs > > >> >>> > > >> >> > > >> >> > > >> >> -- > > >> >> Thomas Mortagne > > >> >> _______________________________________________ > > >> >> devs mailing list > > >> >> [email protected] > > >> >> http://lists.xwiki.org/mailman/listinfo/devs > > >> >> > > >> > _______________________________________________ > > >> > devs mailing list > > >> > [email protected] > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > >> > > >> > > >> -- > > >> Sergiu Dumitriu > > >> http://purl.org/net/sergiu/ > > >> _______________________________________________ > > >> devs mailing list > > >> [email protected] > > >> http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Lerouge > Product Manager - XWiki > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.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
