4 Sep
2009
4 Sep
'09
2:50 p.m.
Hi Thibaut,
"Preview" exists because when writing in Wiki mode you want to see how the
result looks, without saving.
"Preview" has some additional advantages and usages if that certain page is:
- "Watched" (send e-mails on changes and RSS feed) or
- like XWiki.org has the changes connected to the IRC or
- you make small modification that don't want to appear in History until
you're ready to save.
I use "Save&Continue" especially in development (plus the shortcut
*<Alt> +
<Shift> + s*). This way I get to save my changes without losing the line I
am editing.
"Save&View" is a final action that takes you out of the editor. This is
good
for beginners that don't know where the breadcrumb is or how to get out of
the editor.
"Cancel" is a necessity and an idiom than need to exist in actions. Gives
the user the control that he can test and press anything in the interface
without messing things out. If he is there by accident, "Cancel" will make
things right.
I know that you are the adept of normal users that use XWiki, but XWiki is
also a developing platform and needs to satisfy developer needs too.
Although there are 4 actions, they are straight forward and
self-descriptive. Any user knows that "Save", "View",
"Cancel", "Continue",
"Preview" is.
On the other hand "Publish", "Draft", "Update" are more
application specific
(blogs, emails) and it's harder to explain the user the difference between
this words and the "Save". Proposition 3,4: so "Save" is saving the
"article" and "Publish" puts it on server (?!?!?) . Also
"article" is a
constraint word that doesn't exactly explain concept of a XWiki page (it's
not only about words on a page, but also other functionality embedded).
So, IMO XWiki is a lot harder to use for users that want very simple
applications, although we try to make it as simple as we can. The main
advantage of XWiki is the power of its features. Power attracts complexity.
Also a user may not ever know what every functionality does in an
application. If he can find an action that does the trick for him, he will
stick to that. If you didn't know what was every buttons functionality, that
didn't stopped you of using it.
Thanks for your feedback,
Caty
On Fri, Sep 4, 2009 at 14:19, Thibaut DEVERAUX
<thibaut.deveraux(a)gmail.com>wrote;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
(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?
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