The user should interact with objects. For example, a monticello package is an Object, and the user should be able to "install" it. The actions done by a user on an object are like the methods each object has. The object should have an on-screen representation, and the methods should be in a context menu.
The UI should be abstracted from its implementation. Consider, for example, ToolBuilder.
There are several types of on-screen widgets, and they all have a model of sorts:
Buttons, Toolbars, keyboard shortcuts: these have a method as a model.
Listboxes, drop-down lists: these have a special list (which can have one selected item) as a model.
Text boxes, number boxes, date boxes, etc: these have their data type (String / Number / Date) is a model.
Sliders: These have a range and a floating-point value as a model.
By building up a user interface with models, the user interface can have multiple implementations.
UI Flow
A UI should flow from top-left to bottom-right, just like reading a page (in English...). The "Okay"/"Dismiss"/"Close" button should be the last thing you look for, so it should be at the bottom right of a dialog. The "Cancel" button should be to the left of that.
Responsiveness
Squeak is quite bad for making the user wait. The UI needs to be more multi-threaded, and things like Monticello should have their own, backgrounded progress bars somewhere. The whole UI should not block.
Commands
The user interface is controlled via commands, e.g. "Save", "Edit", "Make bold", etc. These could be made objects to which things like buttons, menu items, toolbars and keyboard shortcuts could be bound. Perhaps also integrate a command-line client of sorts into this?
Perhaps - bind the ALT key (on a PC keyboard) to be the command key for the current Morph or Object. E.g. ALT-s does "Save". Holding down the ALT key could show the keyboard bindings (in a virtual on-screen keyboard) for all of the keys - and perhaps also allow re-binding of those keys?
Alternatively, every command which is accessable from a menu / toolbar / button could also have a key binding put on it by selecting "Bind key..." from a context menu... unless a particular object is needed for that command??? Hmm...
Transactions
User interface actions should be un-doable, much like rolling a transaction back. Infact, a transaction-based framework for a user interface would be ideal. Actions would be transactions. Transaction history could be kept, and then an "undo" command would undo the most recent transaction. Your object(?) would have a viewable transaction history.
Feeling at home
Squeak has the notion of Projects (which I like) - click on one, and it becomes your entire screen. What is needed is a taskbar or flaps which are implemented independently of Morphic / MVC / Tweak / whatever, and which stays on the screen. This could have:
a back button.
a home button, taking you to your home project.
history (aka a Web Browser)
a clock.
System menus - save, shutdown, etc.
System-wide configuration.
Cut + Paste UI, showing the currently copied object??
other niceties... a search field ala Firefox??
This taskbar would not be able to be drawn over by the current UI, and it would be unaffected by bad stuff happening in Morphic etc. Infact, perhaps this could be like the Amiga OS; it is the "Desktop" physically behind your current project, of which only the top toolbar is visible.
