| |||||||||||
|
| |||||||||||
Kommander Looks to Shake Up the Desktop (KDE.News)Kommander Looks to Shake Up the Desktop (KDE.News)Posted Jun 18, 2004 17:44 UTC (Fri) by iabervon (subscriber, #722)Parent article: Kommander Looks to Shake Up the Desktop (KDE.News) I've been thinking for a while now that the right way to improve Linux useability is to make the design of user interfaces not require any programming, and make application programming not require any user interface. That is, developers produce functions which are provided to a scripting engine. End-user interfaces are put together by people who are good at that sort of thing, using a simple tool or a simple language to create small files. The essential thing is that people who like to do useability studies are not, in general, programmers, and therefore are not comfortable modifying anything of sufficient code complexity to implement interesting functionality. So the solution is to separate the functionality-providing code from the interface-providing code, such that the former has nothing that impacts the user interface and the latter is all straightforward and explicit one-liners.
(Log in to post comments)
Kommander Looks to Shake Up the Desktop (KDE.News) Posted Jun 20, 2004 18:15 UTC (Sun) by dcoutts (subscriber, #5387) [Link] A similar solution is glade and libglade. The UI designer builds a nice interface with glade (no programming required). The programmer uses libglade to get references to the objects defined in the glade xml file and add script them together with the main program functionality.Of course the glade xml file can be changed later after the program has been written (without recompiling) so it is fairly easy for a UI designer to tweak the interface later or for someone to translate it. A good 'RAD' combination is python, gtk+, liblade and glade.
Kommander Looks to Shake Up the Desktop (KDE.News) Posted Jun 20, 2004 18:40 UTC (Sun) by iabervon (subscriber, #722) [Link] That's a good first step, but I'd actually like to turn it inside out.That is, the programmer first implements the functionality, without any reference to the interface, and then the UI designer takes what amounts to a library of bindings and builds an interface for it. This is a bit like how emacs works: there are functions implemented in elisp, and key bindings and such refer to them. The problem with emacs is that both parts are in elisp, which is difficult for most programmers and UI designers, and the parts get mixed badly due, in my opinion, to the parts being in the same language. I'd like to see a mail program, for example, which consists of functions which fetch messages and send them; added to this would be a user interface which arranges the parts of the message on the screen, handles composition, formulates searches, etc. From the point of view of the functionality portion, the sender address of an outgoing message is an argument; it is up to the UI whether this address comes from the OS, a configuration database, a program-local setting, or a composition window UI element. It would effectively be a version of mh using an in-process API with structured data, instead of command-line arguments, stream IO, and separate processes and executables. The same engine for IMAP/POP/SMTP/local mail transfer/etc would be useable for an interface like pine, an interface like mh, and an interface like thunderbird.
Separation problems Posted Jun 21, 2004 6:13 UTC (Mon) by eru (subscriber, #2753) [Link] The trouble with attempts to entirely separate the UI and application logic is that to implement some UI features effectively, you may need changes to the application, or get information from it that the application-UI interface did not anticipate.To take your e-mail application as an example: suppose the UI designer wants to implement a feature that optionally auto-completes addresses on the To-line based on previously received mails (because it is a good bet you want to send mail to someone you have corresponded previously). The application logic provides a way to list old mail headers from what the information can be extracted, but this is unlikely to be fast enough for the user interface, and even then the UI side has to do some programming to extract just the addresses. To maintain the separation, the UI designer would have to talk the programmer to implementing a fast "list the addresses" function. After a few rounds of this, the UI and the application will be so intertwined it is hardly worth talking of them being separately developed...
Separation problems Posted Jun 22, 2004 2:42 UTC (Tue) by iabervon (subscriber, #722) [Link] I think that this would be balanced out if there are multiple UIdesigners asking the same application team for things. If the application team has good taste (in the sense in which Linus has good taste), they'll come up with solutions to fulfill the requirements in ways that make sense from the point of view of modelling the data. Getting a list of all of the addresses in a set of email messages (or all of the senders, all of the recipients, all of the senders with a particular recipient, etc) is a logical operation, and not particular to a given UI. (A side issue is an easy API for specifying searches). But it seems likely to me that a batch program might want a list of all of the addresses in messages sent within two weeks either to the user or that the user responded to. Keeping the UI separate from the engine allows name completion and searches for other reasons to be specializations of the same general functionality (even beyond the purely UI characteristic of how the user interacts with name completion).
|
|||||||||||