29 Oct
2008
29 Oct
'08
10:51 a.m.
Hi Guillaume,
On Oct 29, 2008, at 10:16 AM, Guillaume Lerouge wrote:
Wiki selection is planned (it would be a wiki selection page at the
beginning of the wizard) and was not added because it does not
change the
logic of screenshots.
Yes I'm +1 for that (suggest fields + list below as it's done for the
RMUI). Basically as it was proposed by Guillaume initially.
I disagree with this proposal. Even though I am its original writer,
I now
think that it is does not suit well the needs of the people we
expect to use
our WYSIWYG editor, for a number of reasons.
1. We do not need link insertion to be fast, we need it to be easy
to
understand for a wiki newbie. If the user is unable to understand
how link
creation works the very first time he's looking at the dialog box,
without
reading any kind of manual, he simply won't try doing it ever
again. That
would be a definite FAIL.
No. We need it to be fast and simple. This is not fast and will make
people move away from xwiki which is a definite FAIL. Usually what
happens in most software I know is that the first time you use the
software you use a wizard and thereafter the wizard disappears since
wizards are a pain and not performant.
Hi,
On Tue, Oct 28, 2008 at 5:30 PM, Vincent Massol <vincent(a)massol.net>
wrote:
I'd rather just have "create link" and in the screen where you select
the location you simply have the option to enter a non-existing page
(which will be marked as such). For example in the filtering combos,
if you type something that doesn't exist, there'll be a text in some
color (say orange) that'll say something like "the link will be
created to a non existing page and users will be offered to create the
page when clicking on that link".
On Oct 28, 2008, at 5:22 PM, Anca Paula Luca wrote:
This is not due to the label itself but to the very concept it's
covering.
Creating a link towards a page that does not exist yet, thus
inviting users
to create it at a later stage is a key wiki concept that has always
been
hard to explain to new wiki users. Whatever the name we choose, it
will not
be an optimal one. A way to improve this would be to add a little
information button that triggers a tooltip explaining that creating
a link
towards a wanted page means creating a link towards a page that does
not
exist yet but that other users are encouraged to create. Anca Paula Luca wrote:
> Marius Dumitru Florea wrote:
>> Vincent Massol wrote:
>>> On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:
>>>
>>>> Hi,
>>>>
>>>> The last proposal for links management in the wysiwyg editor can
>>>> be
>>>> found here :
>>>>
http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wy…
>>> Sounds nice. Some comments:
>>>
>>> * The link menu items should be improved IMO:
>>> - I would put adding an external link at the bottom since it's
>>> not
>>> the most used one
>>> - The labels should be improved. I don't know if "wanted page"
>>> is
>>> obvious (it wasn't for me)
>>> * The screenshots are missing wiki
selection (for multi wiki
>>> installs)
>>> * I'm not sure I like the wizard like approach, i.e. having to
>>> select
>>> some value before selecting others. I think I would have
>>> preferred a
>>> single screen but that's me only.
>> I'm not into the wizard approach also. One reason is indeed the
>> fact
>> that I have to step through 3 dialogs or so in order to insert an
>> internal link. Another reason is that the solution with extended
>> lists
>> is not scalable at all. The Main space on xwiki.org has more than
>> 100
>> pages (I discovered this after I killed next.dev.curriki by trying
>> to
>> view the space index for XWiki space..) so scrolling through these
>> 100
>> pages is a pain. Why not using filterable combo boxes?
>
> Wizards seem indeed a little too much, at least the way I see
> things, that the
> link should be something quite fast to add.
Yep me too
I was thinking about suggest boxes
> since *the user should know already something about where he wants
> to link*. He
> will very very very rarely need to see *all* pages / spaces to
> choose one (it's
> not like he's picking randomly!)
>
> My extreme approach for this would be a suggest in which the user
> would write
> something like:
> <wikiName>:<SpaceName>.<PageName>
> and he would have suggestions for each of the 3 fields.
I agree that's too cryptic and the several suggest boxes ideas is
better.
Now I am
very aware that this might seem cryptic for a lot of users
so just 3
suggest fields could do it. This can also help with:
* not loading the whole list of spaces / pages, since we could load
suggestions
only after we got some hints from the user (the first letter, for
example)
* allowing the user to insert a page that does not exist in the
same input as an
existing page/space, thus transparently creating a link to a new
page (I'm not
really sure we want that, though)((
Forgot to mention, suggest boxes is almost the same thing as the
filterable
combo boxes, in the end, something that would allow you to type and
see the
matches for what you type, but also show you the whole list if you
really,
really want to see it. 2. This proposal was written by a geek, with geeks
in mind, assuming
fantasy use cases. We spend more than 60% of our uptime in front
of a
computer screen and we are used to complex interfaces such as
JIRA's or an
IDE's. Therefore we are NOT representative of what 80% of our
users will
want to use. The interface I have suggested is too complex for a
newcomer
(too many columns, too many options, complex behaviors)
Sure but some options can be hidden by default like inking to an
anchor or to an attachment. Only the one that are always required
should be visible.
3. It does not matter if creating a link in the
WYSIWYG editor
takes some
time. How many links do we expect our users to create in a typical
day?
A lot. BTW this is one of the MAIN purpose of a wiki. It's the ESSENCE
of a wiki (the ability to create link quickly) so I completely
disagree with you.
I do
not think that a typical user will create more than maybe 5 links
a day.
Since the beginning of the week, even though I am a heavy wiki
user, I may
not have created more than 2 links on our intranet. So if it takes
20
seconds to create one, it does not matter whatsoever.
4. We need to guide our users. People are used to their computers'
folder
hierarchy. I'm looking for the Word document that is in my
personal files
folders that is in my My Documents folder on my main hard drive.
Power users
use search. Most users browse. So providing simple browsing as the
main
option for creating links is probably the right thing to do.
Yes that's fine with me provided it's on one screen (like the Mac
Finder column view) and provided that you can also search on that
screen. And provided you can jump directly to choosing a doc name
rather than having to select the wiki and the space (since that
happens most of the time).
5. People who truly care about speed will use the
wiki editor
anyway. It
will ALWAYS be faster to write {{xhtml}} {{/xhtml}} than to click
a button
to trigger a dialog box, then click a macro to select it and so
on. Power
Users tend to use the wiki editor once they feel familiar with the
wiki
concept.
I don't agree. One of our goal with the new WYSIWYG is to make it easy
and nice to use for everyone. It's a bad design IMO to make something
slow voluntarily.
6. As for the technical issue - mainly scalability
of we want to
offer a
list of 150 or so pages with a real scroll (not a JS one). I'm
sure (ok, I
strongly hope) that here are ways to optimize the underlying storage
mecanism in order for it to have an index of all spaces and an
index of all
pages in every space available upon request.
That's the same as the RMUI. Only the visible pages are fetched as you
type.
What's more, it is Laurent's job to have an
insight into what our
customers
and users will expect. The same way I trust you guys for delivering
a great
architecture or clean, working and tested code, I trust Laurent for
proposing an interface that actual users will want to use. I am NOT
an UI
engineer. Designing great UIs requires skills, experience and
patience. It's
all too easy for us to come and give our opinion about mockups.
However if
designing great interfaces was that easy our users wouldn't be
saying that
XWiki is hard to use :-)
I don't agree with this at all. I'm very -1 on this.
There's no single authority when developing an open source project in
a collaborative manner. Everyone can make proposals but they are
*only* proposals. Nobody as more power than anyone else simply because
he's a said expert in the field. People will trust that person on what
he proposes not on his title.
Everyone has the same power to propose something.
So yes I'm very happy that Laurent makes proposals and it's very
likely that his proposals will please people (since he's an expert
designer) but you can't say we have to accept whatever Laurent
proposes *WITHOUT* any justification and *WITHOUT* questioning his
choices.
So even though I would personally benefit more from
the complex UI
I've
proposed, I think the best thing we can do for XWiki right now is to
think
about real people who hardly know how to use a wiki and provide them
with a
dead-simple, wizard-based interface with very little options that
will guide
them through the whole process. Let's accept it: we're not the WYSIWYG
editor's target market. Our mothers are. And my mother would be
definitely
unable to use the interface I've suggested :-)
It's a balance. Right now 99.99999% percent of our user's target are
not your mother (not mine at least ;)). They are people who have used
a computer before and business professionals (and slightly more on the
techy side). but you can't say we'll have a tutorial to explain how to
use a mouse everytime someone wants to insert a link because there are
people who haven't used a mouse yet. There needs to be a limit.
I really think that the WYSIWYG editor should be usable by tech people
too.
Last, even for novice users once they've inserted, say 2-3 links with
the wizard, they'll want a faster way to do so. It must be possible
for a user to simply start typing a page name right away and then
(optionally) select where to put it afterwards.
Thanks
-Vincent
>>>>> * It's missing the ability to
specify any number of parameters
>>>>> (for
>>>>> advanced usages)
>>>>>
>>>>> Thanks
>>>>> -Vincent