konrad wrote: > Edwin (and others), > > great thanks for starting to work on this!
thanks for having a look as well... > I have a number of suggestions for changes, strictly based on > the HIG [1] (except those sentences starting with IMO). 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... 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... > 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 > 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. > > *** 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". if we would want to insist on similar naming i would also prefer "navigation panel" and "source panel" > But all other items do NOT belong here according to HIG, but > into a View menu. on apple... > What also belongs here but we do not have: > Minimize > Maximize shrug > *** View *** again, i don't really like this myself > So this is a new menu following [6]. I suggest: > > Open All Insets > Close All Insets note that this is document specific. 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... > *** 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 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 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 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 > *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.
