Hi Edwin,
thanks for your comments.
leuven edwin wrote:
konrad wrote:
just as a side note; i think it is good to have some directions, but i don't
think we should treat the apple hig as the holy bible (personally i like
apples, but as a fruit).
as i see it many of these ui design decisions (also in the apple hig) are as
much about convention as about logic. apple is one convention, windows another.
lyx runs on many platforms so we should try something which people on all
platforms recognize and don't get lost in...
This is not just a side note, but I think the most important priciple
question!
********
1) I think it was mostly agreed on the earlier discussion (by those who
contributed), that we should stick to one HIG. So I would indeed say
that the HIG (whichever we use) is the holy bible. This is the wrong
place to put personal preferences, because people have different
preferences. We should try to stick as much as possible to the HIG.
If you do not agree to this, then for me the discussion ends here. (No
rudeness meant here - I am willing to discuss how to interpret a HIG and
which way conforms most to it, but unfortunately I do not have the time
to discuss personal preferences, especially by email.)
*********
2) You cited in your proposal Apple's HIG, which I think is a well
thought one (because Apple a) does in general not care too much about
legacy and b) has pretty good usability). Would you have cited Vista's
HIG, then I would have used that.
but let's see:
Instead of having different ui/inc-files circulating around,
I think it makes more sense if you maintain the "master"
version and include from my suggestion what you deem
appropriate. OK ???
sure, but we need to reach some consensus on the list (and solve the shortcuts
issue)
**** File ***
New Window
New Tab
New File
...
IMO: Yes, it looks a bit clustered with all the different New
and Close, but this is what they do (and also removes current
confusion).
current as in lyx 1.5? or current as in the file i send? i think in the latter
there is not much confusion concerning file and windowing/view stuff...
I meant current as in what I proposed. In the file you sent (maybe also
in the standard-ui) "Close" does the wrong thing - it commonly closes
the view, not the file.
Concerning Import/Export:
unrelated to menus...
*** Edit ***
According to HIG, no separator above Select All.
ok
Move Paragraph Up/Down
this is for the edit menu i think, it is about ordering/contents and not
formatting
ok.
and Text/Paragraph Styles would more
be something
for a (HIG-recommended) Format-Menu, but we don't have that
since these four things would be the only entries (?).
that's indeed a possibility
*** Window vs. View ***
According to HIG there should be:
1) a VIEW menu for all what concerns appearance WITHIN a
window and [6]
2) a WINDOW menu for managing the multiple windows. [7]
i think i prefer the current (ie last version i send). i realize that it put
these things together, but it makes a stricter separation between the document
and the view/window.
the reason why i don't like this view menu, is that "view" is a verb and a noun
and this leads to confusion (see below). imo of course.
But there is a View menu everywhere - in the XP HIG, Vista HIG, Apple
HIG, Wordpad, Office 2003, ... Don't refuse just because you don't like it.
*** Window ***
According to HG [5] putting Source and Navigation here is perfect!
I would call them (to be consistent):
"View Source" and "View Navigation"
an illustration of why i don't like this "view" menu too much. it is confusing, is "view on
the document" or stuff you want to "view".
see HIG. like it or not.
if we would want to insist on similar naming i would also prefer "navigation panel" and
"source panel"
If it is under window, then it must have a verb. see HIG.
But all other items do NOT belong here according to HIG, but
into a View menu.
on apple...
and windows.
What also belongs here but we do not have:
Minimize
Maximize
shrug
*** View ***
again, i don't really like this myself
which it isn't about. sorry, maybe introduce next time such a proposal
as "this is what I like" (then there is no right or wrong), but if you
introduce it as "this is following apple's HIG" ... (also maybe I
misunderstood that).
So this is a new menu following [6]. I suggest:
Open All Insets
Close All Insets
note that this is document specific.
I did not know that, I see know. It should not be like this (i.e. Inset
states should be independent in multiple views IMO), but this is another
topic...
so is are we in a document menu or a view menu. confusing if you ask me. another reason
why i am not a fan of a "view" menu...
*** Document ***
There is nothing left for this menu, and the HIG give no
indication whatsoever that we should have this.
but document is less ambigous than view...
But view is standard in the three HIG I looked at, and people are used
to what it means.
*** Navigate ***
Clearly an application-specific menu, everything fine here.
Except: A second level of sub-menus is forbidden. (p.174)
Suggestion: Just put all the lists on the first level (and
group them with a spearator), with the items in the sub-menug.
this will result in menu which is very long. try this with the user guide
I see. Try it with Intro.lyx, and it looks odd.
in fact, i would drop this navigate menu. the navigation panel is much more
convenient.
we could think of a adding a navigate toolbar with buttons for next section,
note, table and the bookmarks...
*** Table ***
Left/Center/Right/Top/... miss a verb.
But: see "Format", I would move it there.
a possibility indeed
*** Format ***
According to HIG this menu should be there [9].
I would suggest:
Capitalize
Uppercase
Lowercase
----------
Customized Text Style ...
Dissolve CharStyle (what is this ???)
----------
Paragraph Style ...
got no idea what that means either;-)
Move Paragraph Up
Move Paragraph Down
for the edit menu
----------
Table > (all into sub what is in Table MainMenu now)
yes
*** Math ***
Looks good. It could go into Format as well, but it is too
large for a sub-menu (and would have sub-sub-menues then).
According HIG it is OK to promote it to a full menu in such a
situation.
i agree
*** Insert ***
Looks good
this is a bit of a mess i think (it is very full with little grouping), but i
do not really see how we can improve it...
, except:
IMO Footnotes and marginal notes are Notes, and we have a
submenu called Note, so they should be there. A note is a
note is a note.
even if there is the word "note" does not mean they have the same use. the
notes in the submenu are more like comments/annotation which do not tend to end up in the
markup of the document
But then let us call the Note-submenu something different (Comment ?).
Because the "Greyed Out" does show in the output. Also, we should unify
the naming of this three Comment items.
i also have some vague recollection of a discussion about this (might be wrong
though), and that they were moved out of the menu also because of convenience.
but logical consistence is more important than convenience. but no
problem if we rename "Note".
(but then again, my memory is notoriously selective and unreliable to others...)
*** Typeset ***
According to HIG this OK to do, but IMO one uses almost
always the same one thing (no matter if dvi or pdf). So I
would not waste a full toplevel, but rather put
---------
Typeset (default)
Typeset >
---------
into File (following HIG-logic it should NOT be in View).
keep if for now i would suggest
... agreed as long as we don't have a 'default' typesetting mechanism
(as discussed elsewhere).
*CONCLUSION 1*
So my top-menus would be (ordered according to HIG):
File Edit View Insert Format Math Go To
Window Help
(one could argue if Go To/Jump should be after View)
*CONCLUSION 2*
I hope somebody made it down to here in this horrendously long email.
;-) But, I really hope we get something better for the menus, soon.
made it
let's see whether this inspires the rest...
ed.
Please decide on how you want to proceed:
a) based on what you think makes most sense (i.e. what you like)
OR
b) based on a holy-bible-HIG.
I have my opinion on this, but I seriously do not know what is more
likely to lead to a success (in the sense of being accepted by everybody
else and ending up in the official version).
/Konrad
