4 Sep
2009
4 Sep
'09
4:47 p.m.
[Preview] [Save & Quit Editor] [Save] [Quit]
+1, love...
About preview by WYSIWYG for my psychology it all depends on how the
editor lets me psycologically able to think is text in context.
I'd may take Knol as an example of it (try to edit) :
http://knol.google.com/k/kel-smith/universal-design-for-the-web/1dup26f8wrw…
For my part XWiki one is too limit to currently fit but i'm very exigent.
I'm not award of the theorics about WYSIWIG psychology, i find it to
be an intersting topic...
Another topic. Does all inclusions renders in WYSIWYG ?
2009/9/4 Jean-Vincent Drean <jean-vincent(a)drean.org>rg>:
Thanks, after re-reading Sergiu's points I think
my preference would go to:
[Preview] [Save & Quit Editor] [Save] [Quit]
I think that if we refactor the edit mode so that the "Source" WYSIWYG
tab becomes our wiki editor [1] the WYSIWYG will de facto become the
easiest way to do a preview, making the preview action quite obsolete.
But it's not for 2.0 :)
[1] To be able to achieve that we implemented Lazy-loading of the rich
text editor: if the WYSIWYG is configured with the source tab as
default the rich text editor is not loaded before clicking on its tab.
JV.
On Fri, Sep 4, 2009 at 3:55 PM, Thibaut
DEVERAUX<thibaut.deveraux(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
"Save
and quit editor" "Save" "Quit editor without saving"
or the shorter:
"Save and quit" "Save" "Quit"
+1 I find it ot be an exellent idea !
It makes evident that when saving only you will not quit.
The longuer may be more securized. I'm not sur it is mandatory anyway.
2009/9/4 Thibaut DEVERAUX <thibaut.deveraux(a)gmail.com>
Time to be structured...
Button naming is hard, especially if wanting to make a platform that is both ergonomic
for normal users and for devs. (!!!)
-- Thinking "ergonomy" does not mean the same for someone who is trying to
bypass the understanding barreer (adoption) and someone who already have the understanding
and who want the tool to be powerfull and efficient (fast and secure editing).
-- Thinking the same world (ie publish) may not have the same meaning.
-- Etc.
So you have to make marketing before making UX... I think Emilie, Vincent, etc... should
start the personas they want on the wiki (it is already made in fact but it only describe
very large profiles that cover all type of possible users, having more real examples and
if possible some priorities would help).
Then we have to draw user actions schemas according to each persona. Saying what zone of
the tool they generally use. For each function define how much each persona will
potentially use it.
Then each time you make a design or proposal think about it. Try to avoid having normal
users lost as much as possible and at the same time try to make the tool as powerfull as
possible for devs (keyboard shortcut only approach can be a good one ie).
I'm sorry, to be honest I don't really like personas and others strucured
anaylsis. I consider they are good for communication or to making people who are not used
to UX enter in a UX perspective. For an UX designer it only make things more rigid wich
not help creativity. Yet... I think they are to be used for heavy projects because if an
eavy project is not structured people who work on it get lost and all lose coherence.
I was not sure XWiki needed such heavy apparel. Yet because of collaboration complexity
and because personas are good for communication I pushed for it.
Caty just made me understand you want an ergonomy for both normal user and devs. Which is
one of the most complicated thing I know. So I think we have to structure it.
Structuring must not avoid us thinking out the bounds. But it should be here to help us
to communicate, to help evryone to understand UX, to help to remember the problematics
evrywhere, to help to create a good coherence.
Also I repeat that we need marketing and management involved in it. UX is not only about
ergonomy but also about emotion, strategic decisions, brand, spirit of the project,
etc...
I propose a vote about this and that someone take the management of this part (an UX
designer or a manager) if XWiki SAS staff agree on that it has to be done.
Thanks.
2009/9/4 Guillaume Lerouge <guillaume(a)xwiki.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi,
On Fri, Sep 4, 2009 at 2:19 PM, Thibaut DEVERAUX <thibaut.deveraux(a)gmail.com
> wrote:
> Personally I never understand thoose different buttons. Just amazing me.
>
> So there the user chains are (tell me if I'm right) :
>
> Use SAVE & VIEW only
> The user is writting a message. He saves it.
> Dangers :
> - He may save and then see errors and come back to modify : why PREVIEW
> exists
> - He may find it to long to save while writting, don't save, loose his
> work. Especially on long messages. Why SAVE & VIEW exists.
>
> Use PREVIEW then SAVE (and sometime modfy again ^_^ )
> - Formated textes
> - User than can't correct a text in edit mode (I do and some friends too).
>
> Use SAVE & CONTINU, SAVE & CONTINU [...], SAVE AND VIEW
> - Long textes
> - User with un unstable internet correction
> - User that get a bit stressed of loosing them work (unstable internet,
> clumsy, just stressed...)
>
> Mix of the precedents
>
> Use CANCEL
> - Undo save & continus
> - quitting edit mode without using a "hack" (back button, close the
> wondows)
>
> Is this ok ?
>
>
> Prpositions :
>
>
> 1 - Simplicity
> SAVE - nothing else
>
> 2 - Simplicity, keeping history a bit clean
> SAVE - PREVIEW
>
> 3 - Full featured
> PREVIEW - SAVE - PUBLISH --------------- CANCEL
>
We actually had a remark from a customer not so long ago who asked us to
rename "Save & View" into "Publish" on their wiki.
It might be a good thing to rename it for the main wiki too as it sounds a
bit clearer and explains well what the result of the action will be (the
document will get published).
As for the "save & continue" button I know I often end up using it as I
would use an autosave. I'm not sure about others but it seems to me that the
default use is to ensure that no content get lost. Maybe we could make the
"save & continue" button create minor edit and rename it to "save
draft" or
simply "save"...
"Save" would meand keep my work secure while "Publish" would mean
"I'm done
with my work, put it online" . The drawback being that the content gets
published even when clcking "save & continue" / "save" /
"save draft" ...
We could also make the preview also be a minor edit save action so that each
time the user previews the page his progress is saved but that kills the
"preview" part...
> (ordered by usage chronology)
>
> 4 - Draft system
> <small>SAVE DRAFT --- PREVIEW DRAFT</small>
> PUSBLISH DRAFT /or/ UPDATE ARTICLE
> <small> Cancel modifications </small>
>
>
> When I'm not making a huge contribution I prefer 2.
> When I'm writting long messages I apprecy the "SAVE & VIEW logic.
> When I'm reading mysefl I apprecy the "PREVIEW" logic.
> I'm an user I want evrything.
> Then I complain I'm getting lost in the interface.
>
> The magic "advanced" menu is not really adapted here.
> So I guess we can have what i call a "sicentific" ergonome approche : put
> evrything and try to make it clear anyway.
> Or what i would call a radical design approche : just kill functionallities
> only a few users use. (we need stats **from average users** or a good nose)
>
> Also maybe someone could find a way to get a simpler usage chain for the
> sames user cases.
>
> I'm for simplest things so I would say 2 (mine), yet I don't have the
> experience of users, netheir the marketing infos.
> So if your really think it is necessary (really ? snif...) I would say 4
> (mine), wich is C (Caty).
> I find the save & ... to be amazing. So I prefer the others.
> What tou you think?
>
>
In the long run we'll need some kind of draft support system and a way to
automatically save page content to prevent data loss. Waiting for that day,
I'm +1 for (C) too.
Guillaume
>
> Thibaut
>
>
>
> 2009/9/4 Ecaterina Valica <valicac(a)gmail.com>
>
> > Hi,
> >
> > Because we want to make a standard from vertical-aligned form, this means
> > the buttons should be left-ordered with the most important action first.
> > This should be changed also in Toucan and Albatross skin, not only just
> in
> > Colibri.
> >
> > Right now the Edit Actions are "Cancel", "Preview",
"Save&Continue",
> > "Save&View".
> >
> > What do you think is the right order for them when they are left-aligned?
> >
> > (A) Save&View, Save&Continue, Preview, Cancel (as it is - just in
> reverse)
> >
> > (B) Save&View, Preview, Save&Continue, Cancel
> >
> > (C) Preview, Save&Continue, Save&View, Cancel
> >
> > (D) other variation
> >
> > Remarks:
> >
> > - "Cancel" should be *last* because it's a terminal (takes you
out of the
> > editor), no-saving action. This is the least important.
> >
> > - "Save & View" is also a terminal action (takes you out of the
editor) -
> > having it* first* you have the 2 terminal actions at extremities.
> > - "Preview" is the least damaging action in case of accidental
submit
> > (Silvia + Marta) - should be *first*?
> >
> > - Some people use ("Preview" + "Save&Continue") {many
times} +
> "Save&View"
> > {final}
> > - Other people just use "Save&Continue" + "Save &
View" {final}, never
> > "Preview", etc
> >
> > - What is the necessity for the "Preview" button in a WYSIYWG editor?
On
> > the
> > other hand "Preview" is very important if you edit in
"Wiki" mode.
> >
> > - Should "Preview" separate the two other SAVING actions? (Marta)
> > - Should "Save&Continue" separate the two other VIEW actions?
> >
> > Thanks,
> > Caty
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs