29 Nov
2008
29 Nov
'08
9:47 a.m.
On Nov 29, 2008, at 6:17 AM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
I'm surprised by your reaction Laurent.
JV is proposing to have a 2 step wizard for inserting an image. I
comment that the second step is not necessary IMO since it only
contains optional features that are not going to be used in the
majority of cases (especially if we agree that resizing should be
done
inline and not in the dialog box - You didn't even answer that part,
does it mean you think resizing should not be done inline?) and you
end up the conversation saying that you don't know what to answer...
I think you're missing the fact that a good discussion is always
healthy. You might think that you're always right and that there's no
point in discussing with others but that's simply not true. Look at
your initial proposal with 5 wizard screens. This is what we would
have now if we had blindly accepted your proposal. I'm glad we didn't
since this has lead to thinking more about it and JV proposed the
treeview solution which has had unanimous approval and is better
according to everyone.
OTOH maybe you're fed up discussing because you've already discussed
all this with JV before. Fair enough but then none of us was involved
and we can't know what was discussed.
In addition I don't think we're far from having found our best
solution. Once more my only remaining concern is to systematically
force users to go through a second screen that they would not use.
While this is ok the first time I think it would hamper usability
after a few image insertions. Actually I have another concern which
is
how to use the treeview to efficiently choose an image. While
choosing
the image based on its name is possible I remember seeing other wikis
that are doing better by showing image galleries to pick from.
There's a difference. An image gallery works when the images are in
one
or few places, not when you have thousands of pages in hundreds of
spaces (think Curriki), most of which are of no interest to you.
TANSTAAFL. No UI is the best for all people and all use cases. We
could
have several ways of choosing an image: tree based, most recently
used,
media gallery collecting pictures from different sets of pages
(current
page, current space, all wiki, recently changed documents, recently
uploaded images, ...). The user would choose the best for him, or the
best for the given scenario.
+1. This is also what I was suggesting when I was proposing an option
to switch from the treeview to an image gallery mode. I also would
like to see inside the treeview a branch labelled "Last viewed pages/
images".
Thanks
-Vincent
On Nov 28, 2008, at 2:59 PM, Laurent Lunati
wrote:
> Le 28 nov. 08 à 14:12, Vincent Massol a écrit :
>
>> On Nov 28, 2008, at 1:59 PM, Laurent Lunati wrote:
>>
>>> Le 28 nov. 08 à 12:35, Jean-Vincent Drean a écrit :
>>>
>>>> On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol
>>>> <vincent(a)massol.net> wrote:
>>>>>> 2 steps do not seem excessive to me, it's still gonnna be
real
>>>>>> quick
>>>>>> and it
>>>>>> adapts well to the various use cases we are faced with (insert
>>>>>> link,
>>>>>> insert
>>>>>> image etc). It has both the benefits from the wizard and the
>>>>>> treeview. I
>>>>>> think it is a great middle ground between our various
>>>>>> proposals.
>>>>> You didn't comment on my proposal to be able to click insert on
>>>>> the
>>>>> first screen if you don't need any option applied to the
>>>>> image. I
>>>>> think it's reasonable and saves unnecessary clicks.
>>>>>
>>>> See
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMo…
>>>>
>>>> I'm fine with this solution, Laurent WDYT of this one ?
>>>>
>>>> JV.
>>> it's not the right way for me, with a direct insert button common
>>> usage is :
>> Exactly my point! This is exactly why I've always thought it was
>> better to show the second screen so that the user can see what the
>> options are before clicking on insert (that's proposal 3).
>>
>> The more I think of this and the more I think it's wrong to use a
>> wizard to *force* a second optional step for inserting an image
>> (especially when in the second screen won't be used at all in most
>> cases).
Most wizards I've seen in Excel have Next and Done buttons. A user can
go through every step, or he can "be done" at any moment, leaving the
defaults for the unexplored steps.
Resizing an image is not an option that people will
systematically
choose (quite the opposite) and moreover a much better way to
resize
an image is to use the mouse and resize the image directly in the
text
as it's done currently with tinyMCE (only problem being with very
large images spanning more than the viewport). I'd hate to loose
that
feature.
The scenario by Laurent below simply shows that using a dialog
box to
resize an image is wrong. In order to know the correct size you
need
to see it in the page with the rest of the layout so it's way
better
to offer mouse handles to resize it inline IMO.
I really don't know what to anser.... so starting here i stop to
discuss. Sometimes I just want to link to a precise
image, and I can go to it "with my eyes closed", sometimes I want to
insert a bluey image, and sometimes I want to use an image I remember
seeing a few days ago somewhere, can't remember where exactly, but
somewhere in one of these 5 documents.
We could use Google Gears to keep track of the last preferences, since
cookies are too expensive, and serverside increases the storage
needlessly.
But that's for the future.
Hope you'll reconsider and continue
discussing here.
Thanks
-Vincent
>>> 1 - select
>>> 2 - insert
>>> 3 - Ho zut
>>> 4 - edit ?
>>> 5 - ho... am i on the right box ?
>>> 6- click on edit (or close the dialogue, in this case delete img
>>> and
>>> reclick on insert image)
>>> 7 - reselect img
>>> 8 - ok more options...
>>> 9 - ha... yes my image is too big
>>> 10 - change option
>>> 11 - insert
>>>
>>> if you have 2 steps on inserting dialogue always display all step,
>>> so
>>> that user always know where he is
>>>
>>> laurent
This is a scenario. A possible one. But not a frequent one, and most
certainly not the most common. So a few users will have to loose some
seconds a few times until they learn how to do it the right way. But
it
will also save a little time from everybody else EVERY time. A little
bit every time versus a bit more on a few occasions is an obvious
choice
for me.
Usually IT solutions are chosen and imposed in a company. If some
guy or
gal gets his little brain confused by the fact that more options are
behind the "more options" button, he won't matter. Brainless
secretaries
don't make IT decisions. They are a big part of our users, but they
are
not the ones that decide what product to choose.
I tend to believe that we are trying to develop a powerful wiki. XWiki
has many features nobody else has (yet), and it is certainly not
targeted as a Word replacer (Google Docs does a good job here). If
users
need power, they will choose XWiki. If they just need something to
write
notes on, then I personally wouldn't recommend XWiki to them to begin
with. Yes, a few people chose something else because of the WYSIWYG,
but
not because it was a tad more difficult to use, because it was REALLY
BUGGY, and I agree with them. Our TinyMCE editor is almost useless for
anything more complex than writing a plain letter with a few bold
words,
and I never use it because of this. As long as we have as little
bugs as
possible, and it doesn't prove to be extremely complex, I say we're
safe.
More, if a client really needs a simple UI that can be used by a group
of mentally retarded children, we can always do some custom
development.
It is important to have a configurable editor, not to have ONE
interface
that can satisfy everybody from hard-core hackers and 3-year
youngsters.
By the clickety current look of the WYSIWYG editor, I am pretty sure
I'll stay away from it.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs