>Hi! Sorry for my absence, struggling to slay the dragon Thesis...
>
>Regarding the GUI, I must ask for some "paramaters". My understanding is that
>we the GUI we are developing will be substantially different from that used by
>MC, and will _not be merely cosmetic changes.
Eric,
we will need to re-organize lots of stuff. That is, e.g. some things are
in the wrong tabs (= folders in your terminology), some frequently used
features are in sub-windows of palettes when they should be in menus, while
other seldom-used features could easily be removed from the menus to
lighten the UI a bit. Examples:
- The "import" window could just be a menu item with a submenu, or we
should at least turn the tabs into radio buttons or a popup menu.
- Management of MC's backgrounds can use improvement, maybe using a
"layers" palette like Photoshop instead.
- Most things in the "Tools" menu should go into external stacks, they are
usually only used once and shouldn't be part of the UI. The rest of the
items in there should go in a "Window" menu at the right end of the menu
bar.
- We need a "Go" menu, which is more convenient than the "Navigator"
window, since the latter is more useful if you have to scan a list of
cards, while during development you only advance by 1 or two cards.
Navigator could be a window in there.
- The message box should be a floating palette.
- We need a stack hierarchy window (collapseable list of stacks,
sub-stacks, backgrounds & cards + parts on them), since with substacks it's
hard to navigate through the file otherwise. Most of the buttons in the
"Stack Info..." window's "Properties" tab should be moved to this palette.
We should propably combine this with the control browser and the resource
mover (which needs a complete redo).
- We need a user property editor. Best bet is one like SC has.
- The Menu builder needs to be redone to be WYSIWYG, probably like
ResEdit's menu editor.
- Audio settings should be rolled into the Preferences
- A preview how a button's attributes will look if it isn't instantly
applied to the button
- The "Toplevel" button next to the "Menu name" should probably also be
changed to "Open it", and "Menu name" should be changed into "Menu stack"
or something like that, so people know at once it's not the menu's title
but the name of the stack to display as a menu.
etc.
>(Cosmetic changes = new background color, new fonts, new graphics, changes in
>size of palettes)
The colors aren't that bad. Too much color can hurt. But we should make
sure OK buttons are always in the lower right etc.
>In MC we have "folders" which present all object attributes. I actually do not
>have a problem with this approach. In fact, I find the MC GUI at least
>adequate. Certainly I think that cosmetic changes are necessary, but beyond
>that I must ask our objectives: More "menu items" in the menuBar?
Reorganization, mostly. These "folders", or tab panels as others like to
call them should be examined closely, since some features are under
inappropriate headings. E.g. Tool Tips under "behaviour", while icons
should go under "appearance" etc.
>Really, I think the MC GUI is a little slow (which I attribute to my _non
>accellerated 68030) compared to HC but and does take up lots of desk space
>(six open windows is actually not uncommon: tool palette, scripteditor, object
>editor, and maybe home and help...) but that will be adressed by changing
>sizes of the stacks in question.
It's not that fast, but the speed is acceptable. SC's runtime editor was
what I'd call slow.
>So my question is, in terms of GUI what changes are to be made _other than
>cosmetic. A simple 'facelift' of the MC GUI would be an improvement, and can
>be presented soon (in fact, I am prototyping a version with a 'cream'
>background, blue textfont, using chicago and monaco...) but before I do the
>palette (gradient shades of gray create a 'metallic appearance' and will
>reverse - requiring 32 different icons - in HC just an afternoon, but in MC
>because I'm still a beginner will take 2 or 3 days) I want some 'feedback' on
>our Grand Objective: Is it to create a _completely different interface - if
>so, in what respects?
Gradients are not the problem. The symbols themselves are not expressive
enough. Take out your copy of photoshop and draw a hand that looks like a
hand, and also has a proper color to be recognized as skin. The image tool
has the wrong icon, it should rather be some picture (a "la joconde" is
rather frequently used for things like that, or some other "painting").
>I look forward to your replies and guidance. I honestly feel some simple
>cosmetic changes would be sufficient - however I am happy to go 'one step
>beyond' - after people tell me where to go... (;->
I have enough listed above. If you need more, notify me. Oh, BTW, the
script editor could also use some improvements.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
