4 Sep
2009
4 Sep
'09
1:08 p.m.
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
4 Sep
4 Sep
2:05 p.m.
Ecaterina Valica wrote:
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
I was going to vote for (C) without further thought, but there's one
important issue you raised: in the WYSIWYG editor the preview is not
that useful. Here are some more arguments in favor of putting Preview first:
When a non WYSIWYG editor is used, it's critical to use the Preview
button, and putting it first helps. For consistency, the number and
order of the buttons should be the same in all editors.
The problem with the Cancel button being first was that it was the
default form button, so pressing enter in a non-textarea field was the
same as clicking cancel, thus the "oh my 50 minutes work is all gone"
frustration. Preview is the least destructive action: it does not cause
data loss, it does not cause an accidental save of work in progress
data. Thus, it should be the first button.
Even in the WYSIWYG editor, sometimes Preview helps. The width and
height of the content is not the same, the panels are different, the
background might be different (IIRC the WYSIWYG always uses a white
background, while the theme might be different), the macros look
different...
Remarks:
- "Cancel" should be *last* because it's a terminal (takes you out of the
editor), no-saving action. This is the least important.
+1
- "Save & View" is also a terminal
action (takes you out of the editor) -
having it* first* you have the 2 terminal actions at extremities.
+0.5
- "Preview" is the least damaging action in
case of accidental submit
(Silvia + Marta) - should be *first*?
+1
- 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?
So, final vote for me, (C)
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
2:19 p.m.
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
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
2:54 p.m.
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>
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.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
3:06 p.m.
On Fri, Sep 4, 2009 at 2:54 PM, Guillaume Lerouge<guillaume(a)xwiki.com> wrote:
We actually had a remark from a customer not so long ago who asked us to
rename "Save & View" into "Publish" on their wiki.
About renaming, WDYT of:
"Save and quit editor" "Save" "Quit editor without saving"
or the shorter:
"Save and quit" "Save" "Quit"
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"...
Saving as a minor edit on "save and continue" sounds good. "Save
draft" will be nice when we'll have a real draft feature (ie. saved
but not published).
"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" ...
There's something bothering me with "publish" but I don't know what,
may be the CMS connotation.
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...
-1
JV.
3:32 p.m.
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>
Hi,
On Fri, Sep 4, 2009 at 2:19 PM, Thibaut DEVERAUX <
thibaut.deveraux(a)gmail.com
left-aligned?
the
On
--
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
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
(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
> 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?
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
3:55 p.m.
"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>
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>
--
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 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
4:14 p.m.
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:
"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
4:40 p.m.
-1 on Quit. Quit is when you QUIT an application, just like Exit. When you
press that button you don't quit your wiki, you just leave the editor.
4:58 p.m.
I felt it a bit too, was my problem about securizing. So if you felt
it too I add my +1
--- [Quit editor] ???
I would say code more than source. Source sounds like a dev jargon terme to me.
2009/9/4 Ecaterina Valica <valicac(a)gmail.com>om>:
+1 on Wiki code should be named "Source".
On Fri, Sep 4, 2009 at 16:40, Ecaterina Valica <valicac(a)gmail.com> wrote:
-1 on Quit. Quit is when you QUIT an application,
just like Exit. When you
press that button you don't quit your wiki, you just leave the editor.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
5:07 p.m.
New subject: [xwiki-devs] [xwiki-users] [UX] Edit Buttons Order
Ecaterina Valica wrote:
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
+1
Thanks,
Marius
(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
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
5:11 p.m.
+1 for (C)
-1 on Quit. Like Caty says Quit is used for quiting applications.
I think "Save and View" & "Save and Continue" are good name
choices that
serve their purpose. I think we should keep them provided we don't receive
additional user/customer remarks.
Ecaterina Valica-2 wrote:
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
Thanks,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
-----
Silvia Rusu
Tester & Documentation Writer - XWiki
http://twitter.com/silviarusu
--
View this message in context:
http://n2.nabble.com/UX-Edit-Buttons-Order-tp3579224p3580564.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
14 Sep
14 Sep
11:04 a.m.
Ecaterina Valica wrote:
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.
I just noticed the change made on all skins, and I don't find it comfortable to
have this change in toucan because:
I think, as in the case of titles policy, that we're building a new, better skin
and changes like this should be in the new skin. I find it disturbing to have
different order for buttons than I was used to, and, although I agree to get
used to it in a new skin, I don't find it appropriate that I have to get used to
it on the old skin too.
I think users should be able to preserve their beloved skin which they're used
to if they want, including buttons order.
Caty motivated this change across all skins with the fact that form design
(alignments, buttons order, et all) it's a platform standard and platform
changes are applied to all skins.
I think these standards are UI/UX/ergonomy standards and they should only be
preserved across a skin. On the very same platform one could build a right
aligned skin, it doesn't impact the platform in any way, I don't see why we
would impose this as a "platform thing".
This is the type of annoying change for a user (I keep going to the wrong side
of the screen with my mouse) and, while I'm ok with getting used to it on a new
skin, I find it slightly frustrating on the skin I was used to.
Happy coding,
Anca
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
11:34 a.m.
On Mon, Sep 14, 2009 at 11:04, Anca Luca <ancapaula.luca(a)xwiki.com> wrote:
Ecaterina Valica wrote:
We agreed that this order caused confusion between some users and was better
to be changed.
You're saying something like: don't change it (even if it's broken), just
because I'm used to it.
The change was made for the benefit of all users.
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.
I just noticed the change made on all skins, and I don't find it
comfortable to
have this change in toucan because:
I think, as in the case of titles policy, that we're building a new, better
skin
and changes like this should be in the new skin. I find it disturbing to
have
different order for buttons than I was used to, and, although I agree to
get
used to it in a new skin, I don't find it appropriate that I have to get
used to
it on the old skin too.
I think users should be able to preserve their beloved skin which they're
used
to if they want, including buttons order.
Caty motivated this change across all skins with the fact that form design
(alignments, buttons order, et all) it's a platform standard and platform
changes are applied to all skins.
I think these standards are UI/UX/ergonomy standards and they should only
be
preserved across a skin. On the very same platform one could build a right
aligned skin, it doesn't impact the platform in any way, I don't see why we
would impose this as a "platform thing".
This is the type of annoying change for a user (I keep going to the wrong
side
of the screen with my mouse) and, while I'm ok with getting used to it on a
new
skin, I find it slightly frustrating on the skin I was used to.
11:45 a.m.
Ecaterina Valica wrote:
On Mon, Sep 14, 2009 at 11:04, Anca Luca
<ancapaula.luca(a)xwiki.com> wrote:
Yes.
but only in the current context, when we _are_ actually fixing _all_ these
issues, by building a new skin, otherwise I don't see why we build a new skin
and not fix the one we have.
Now I'm not trying to justify the new skin by not merging the fixes in the old
one, it's just that this is the kind of annoying change and, since we are
dramatically improving everything in a new skin, I don't see why annoy users and
apply these disruptive changes in the old skin too.
just my 0.2 cents...
Thanks,
Anca
Ecaterina Valica wrote:
We agreed that this order caused confusion between some users and was better
to be changed.
You're saying something like: don't change it (even if it's broken), just
because I'm used to it. 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.
I just noticed the change made on
all skins, and I don't find it
comfortable to
have this change in toucan because:
I think, as in the case of titles policy, that we're building a new, better
skin
and changes like this should be in the new skin. I find it disturbing to
have
different order for buttons than I was used to, and, although I agree to
get
used to it in a new skin, I don't find it appropriate that I have to get
used to
it on the old skin too.
I think users should be able to preserve their beloved skin which they're
used
to if they want, including buttons order.
The change was made for the benefit of all users.
Caty motivated this change across all skins with
the fact that form design
(alignments, buttons order, et all) it's a platform standard and platform
changes are applied to all skins.
I think these standards are UI/UX/ergonomy standards and they should only
be
preserved across a skin. On the very same platform one could build a right
aligned skin, it doesn't impact the platform in any way, I don't see why we
would impose this as a "platform thing".
This is the type of annoying change for a user (I keep going to the wrong
side
of the screen with my mouse) and, while I'm ok with getting used to it on a
new
skin, I find it slightly frustrating on the skin I was used to.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:19 p.m.
So basicly you have a set of user that are used to the old way. Theses
users will see that one day, the order of the buttons change and they
get lost during a few days, cliking on the old places of buttons.
UX Design field, and especially ergonomy are full of "historical
reasons", things that have not been changed because of it. I remember
of such sort of thing about keyboards ie.
Another example is some dyctalos that always use anachronic versions
of MS Word on old computers because they are used of it.
An historical reasons is a good thing for user that are used of
something. Evrything depends if there is an impact on new users and
further generations.
So if there is a further generation of users on toucan consider that
they will be penalised by the historical reasons.
World is already so full of anachronysmes... ;-)
2009/9/14 Anca Luca <ancapaula.luca(a)xwiki.com>om>:
Ecaterina Valica wrote:
On Mon, Sep 14, 2009 at 11:04, Anca Luca
<ancapaula.luca(a)xwiki.com> wrote:
Yes.
but only in the current context, when we _are_ actually fixing _all_ these
issues, by building a new skin, otherwise I don't see why we build a new skin
and not fix the one we have.
Now I'm not trying to justify the new skin by not merging the fixes in the old
one, it's just that this is the kind of annoying change and, since we are
dramatically improving everything in a new skin, I don't see why annoy users and
apply these disruptive changes in the old skin too.
just my 0.2 cents...
Thanks,
Anca
Ecaterina Valica wrote:
We agreed that this order caused confusion between some users and was better
to be changed.
You're saying something like: don't change it (even if it's broken), just
because I'm used to it. 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.
I just noticed the change made on
all skins, and I don't find it
comfortable to
have this change in toucan because:
I think, as in the case of titles policy, that we're building a new, better
skin
and changes like this should be in the new skin. I find it disturbing to
have
different order for buttons than I was used to, and, although I agree to
get
used to it in a new skin, I don't find it appropriate that I have to get
used to
it on the old skin too.
I think users should be able to preserve their beloved skin which they're
used
to if they want, including buttons order.
The change was made for the benefit of all
users.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Caty motivated this change across all skins with
the fact that form design
(alignments, buttons order, et all) it's a platform standard and platform
changes are applied to all skins.
I think these standards are UI/UX/ergonomy standards and they should only
be
preserved across a skin. On the very same platform one could build a right
aligned skin, it doesn't impact the platform in any way, I don't see why we
would impose this as a "platform thing".
This is the type of annoying change for a user (I keep going to the wrong
side
of the screen with my mouse) and, while I'm ok with getting used to it on a
new
skin, I find it slightly frustrating on the skin I was used to.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5534
days inactive
5544
days old
18 comments
8 participants
participants (8)
-
Anca Luca -
Ecaterina Valica -
Guillaume Lerouge -
Jean-Vincent Drean -
Marius Dumitru Florea -
Sergiu Dumitriu -
Silvia Rusu -
Thibaut DEVERAUX