Model View Controller and Event Driven UI
From CS160 User Interfaces Fa06
Lecture on Oct 23, 2006
Readings
- Basics of Event Handling. Developing User Interfaces. Chap 4. Olsen.
Demos
- The link for firebug that allows browsing javascript widgets is here: https://addons.mozilla.org/firefox/1843/
- The simple Java code Jeff browsed in class using Eclipse is here
Jeff's instructions for browsing this code:
When using the Eclipse debugger you step into a class that is part of the Java runtime library, by default a not-so-human-friendly description of the class is presented in the code editor pane. To see the actual source code for many of these classes, click the "Attach Source" button. In the resulting dialog, browse to your JDK installation's root directory and select "src.zip". I know that the source is included with JDK 1.4.2, not sure about 1.5 and 1.6. If not included automatically, go to the JDK download pages at Sun, and you should be able to download the source bundle from there. Once the source has been attached within Eclipse, you will be able to walk through the pure Java parts of the JVM source code. One note: make sure the version of Java you are using in your Eclipse project matches the version of source code you are attaching!
Andrew Hao - Oct 20, 2006 12:03:07 am
Event-Driven UI: I found this dicussion of event-driven interfaces both dry and fascinating (well, it's growing on me). The fact that event-driven interfaces have no linear (read: predictable) stream of execution continues to fascinate me (as well as scare me). I've never worked with event-driven models before (save for a little Javascript here and there, but even then I was faking it) so I found this a helpful refresher on events, callbacks and window methods. It's fascinating what's under the hood; I have much greater respect for application UI design and look forward to our project with a mix of excitement and dread. Probably much more the latter.
Jonathan Yen - Oct 19, 2006 04:18:22 am
In my opinion, it seems that this reading is every bit as technical as the reading on human information processing, but more technical in the area of the machine end of UI rather than the human side of the spectrum. One thing that kept coming to mind as I was reading this was the notion of transparency, and how there are so many details involved in event handling and other features of UI software that we simply don't recognize while using the UI. I thought the part on windowing systems was rather interesting. After that, I had some trouble trying to understand the differences between different types of event handling and object communication models.
Hiroki Terashima - Oct 21, 2006 04:33:43 pm
Learning about X's event-handling system made me realize why scrolling down xemacs at home while ssh'ing to one of my cs accounts takes such a long time. If you have a slow network, you're hosed trying to use X. NeWs is a creative solution. Java's AWT/Swing apps provide another solution, and aside from the initial downloading time, this allows quicker response time/better usability. Handling events can be made complicated by the fact that users can use modifiers, double-click on things, right click, middle click, click and release at different positions, etc. I'd hate to be a programmer for handling this logic. Pseudoevents allows microsoft word's side scroll bar to move to match the location of the word that you searched for in the document; it's not a user's direct manipulation of the scroll bar.
This reading is useful in understanding the complications when coding the gui's for our projects. My group will be using Java's SWING. We'll have to handle penstroke events as well as keyboard/mouse inputs for displaying statics and creating ballots. The lesson is, and usually is, KISS: don't try to over-complicate things.
Ramy Ghabrial - Oct 21, 2006 04:39:04 pm
I found this reading to jump around a lot between Windows, Macintosh and X. Perhaps a more focused analysis would have helped. In particular, how does Java handle windows? In any case, it was interesting to glimpse the complications behind windowing interfaces. I am hoping that we will not have to spend much time on this type of programming and debugging because it does seem painful. I was not aware that scrolling text in a word processor merited such a long explanation.
Patti Bao - Oct 21, 2006 05:02:37 pm
I think this article really illustrated how much more complex it is to design for programs that users control (via direct manipulation) as opposed to programs that control users (or at least tell the user what to do). Not only does the program have to be prepared to handle any type of user-directed event, but it also has to ensure that the objects controlled by these events are able to communicate effectively with each other. Any psuedoevents that are unaccounted for will show up as glitches in the interface - something I hope we can all deal with in building our next prototypes.
Kang Chen - Oct 22, 2006 10:22:56 am
Before reading this article, my impression was that once the GUI design was done, it's only a matter of time to program it to communicate with the backend. It never occurred to me that the interface between the frontend and backend could be so complicated. In regards to the article, I think it did a very thorough job of depicting the strengths and shortcomings of each design. The X system seemed so flexible as it plays with different types of hardware fairly well and also allows networking between devices but the amount of information being sent is unnecessarily redundent. Some of the other designs seemed a lot more efficient but the tradeoff was complexity in forcing programmers to manually handle events in the events table. This, along with manual memory allocation and lack of language support for object orientated structures in C would be a nightmare. Near the end of the article, the author brought up objective-C and NeXTSTEP. Even from my limited experience with objective-C, I can say that objective-C is a lot more programmer friendly than C as it integrates the notion of OOP in its design instead of just another layer built upon C. Another thing to note here is that Apple acquired NeXTSTEP (either this or the other way around...) sometime ago and most, if not all, of the applications on Mac are written in objective C and Cocoa for the GUI. The two combined allows programmers to quickly get a functoinal application w/ GUI running and abstracts away all those complications mentioned in the article.
Bowen Li - Oct 22, 2006 11:47:02 am
It's interesting that they mention NeWS is more advanced than X, but most linux distros nowadays still use X. In fact, I've never even heard of NeWS or FORTH.
Another note I found interesting was their explanation of single-click actions in X. I know in that KDE has a lot of single click defaults that are double-click in Windows, but I associated that with an idiosyncracy rather than a practical application such as network timing issues.
I agree that it's frustrating for programmers beginning with event handling to find that there is little or nothing in the 'main' routine of a program. I think there should be a greater focus on event-driven programs because they define how we interact with technology today.
I found this reading to be overall too specific. It seemed as if it was going through a bunch of examples, without any specific point to it.
Tony Yu Tung Lai - Oct 22, 2006 06:27:26 pm
I think the most interesting of this article is probably where Olsen talked about the main event loop and the example of it (figure 4-7). I can see how surprise one would be when he/she first this "main", as that happened to me not too long ago. Looking at the function made me realize how big of a pain it'd be to debug this program using my usual debugging method. This is probably another reason why UI designs need to be tested by actual human users so frequently, as that seems to be the best way to debug a windowing system.
Michael Moeng - Oct 22, 2006 08:01:00 pm
From this reading, we could see how simple changes could drastically affect the complexity of an interface. The "upgrade" from the simple callback model to the parent notification model strips away lots of complexity, especially for larger programs since each sub-window needs only to report to its parent. I wonder how this model would work, however, when a window needs to communicate with another window that isnt above it in the hierarchy, but possibly in another tree--since it is not always possible to associate related objects in the same program tree.
Randy Hilarbo - Oct 22, 2006 08:22:03 pm
I never really dealt with windowing system before so I thought that implementing this is a little scary. But this article provides an introduction of such system good enough for me to realize that it is doable. It's nice to understand how really nice-looking GUI is actually structured in a very organized way such that it is similar to the kind of programming paradigm I am used to. The way windowing system is represented as trees and how each mouse-clicks hid pointers to procedure calls that instruct redrawing of windows reveals the secret behind the complex graphical representations of software applications.
Ming Huang - Oct 22, 2006 08:43:51 pm
Olsen’s take on the event-based user interface sounds to me more of a conceptual interpretation of the interface elements than a technical guide on their real implementations. For example, in today’s windowing systems almost none of the elements are ever represented internally as a non-rectangular shape. Because this approach to managing interfaces fragments are so simple, software designers have insisted on this abstraction even when implementing objects of irregular shapes. Folders, documents, and even the X-eyes programs actually DO claim rectangular regions of screen space, but have just made some parts of them transparent so that they look non-rectangular.
In his discussion on event-dispatching, I was not too convinced by the hypothetical discussion of scenarios which higher levels of dispatching may be desired. Not only did it violate usability rules, but it also disregards all the functionalities put forth in the front of the chapter that does allow finer control of the dispatching, like an event filter. However it is agreed that a top-down approach allows more flexibility.
Compared to previous readings, this one (finally) sounds more like computer science literature than history or cognitive science. I am not trying to understate the importance of studying human behavior or psychology, but it is gratifying to see this class starting to get to more details than just concepts. I wonder how much of these architectures still hold true and is used today (maybe except the Microsoft one, bleh).
Patrick Rodriguez - Oct 22, 2006 09:58:59 pm
Interesting history lesson on the development of GUIs. I just glossed over the details about X and classic MacOS, and it seems like it was somewhat involved to implement a good GUI. These days, you just drag a few controls around in Visual Studio, write up a few lines of code for the event handlers, and you have yourself a functioning Windows application. It's not really as simple as it seems though. The basics are pretty easy, but once you start wanting to do more flashy things, it might get a bit confusing. Keeping track of all the different events than can occur, and what comes before what, and how to handle each. It can get overwhelming. But most people prefer a GUI to a command line interface, so it really is worth the trouble. But comparing now to then, in terms of simplicity, we've made great strides. Just imagine how easy this will be in 10 years.
Maksim Lirov - Oct 22, 2006 10:09:57 pm
The main point that I took away from this reading is that there is much complexity behind the scenes of user interfaces to make them work. Designing a good user interface for an application is one thing, but it is just as important to know how to design the "backend" that can handle all the possible inputs coming through the user interface. The progression from the general main event loop to the modified object-oriented event dispatching loop in figure 4-14 was interesting. However, I was at times confused by the references to XWindows, Windows, NextStep, and Mac OS and sometimes had trouble keeping track of which features belonged to which system. Nevertheless, it was interesting to see how the some of the differences between NextStep, Windows, XWindows, and Mac OS.
As a sidenote, like Bowen's comment above I didn't know about NeWS before this reading and am wondering why X windows is used by most *nix distributions and none seem to be using NeWS if it is indeed superior.
Tak Wong - Oct 22, 2006 10:06:52 pm
When I started reading this article, I thought all these issues of handling clicks and drags are operating system issues and not too much of an interest in UI. It was not until they mentioned the double clicking on X through a network that I realized that not only is this a serious operating systems problem, but it's also an usablility issue. It makes me wonder how double clicking works on remote desktop for windows. The load speed of things in general seem to be pretty fast except the inital login screen. It's much faster than exceed. How is windows different from X in this respect?
Robert Taylor - Oct 22, 2006 10:12:03 pm
I feel that the justifications for the event driven model and complexity in describing its mechanics are antiquated in that they try to reconcile modern window based GUI's with command line input. First, I feel the author is fundamentally wrong in seeing these models as so different - of course on the surface they are different, but a command line prompt, the way I see it, is also very event driven. The computer does not just do something on its own; it is driven by input events from the user. Much as the user would click a mouse the user would type in a command to start an event.
The reading starts to pick up as the author describes window messaging and mouse input optimizations. It was fun trying out some of the optimizations the author mentioned, specifically trying to specifically get around them to see if I could cause significant lag in X.
I must say it is amazing how much effort is required for an efficient Windowing system. It isn't until much later in the reading that the author really begins to differentiate CLI from windowing by showing the almost insane complexity of windowing systems that are not even that new.
Alex Wallisch - Oct 22, 2006 06:54:28 pm
While I have a little bit of experience working with the event model, there were many aspects of it that I had never really considered. My experience was at a very high level; if I had a scrollbar on the page, it would be in the form of a Scrollbar object that would have events scrolledDown(newPosition) and scrolledUp(newPosition). I'd never really taken the time to think about the smaller events that compose a scroll event, such as the mouse entering the region, clicking, and moving. In fact, many of the very low level events discussed in this chapter are things that I never really realized at all. To me, it's always been natural that a scrollbar holds onto the mouse focus even when the mouse moves off to the side, but now that I think about it, somebody had to specifically make it do that, and I doubt that the first scrollbars had this feature.
Vahe Oughourlian - Oct 22, 2006 11:26:00 pm
While I understand the value of this reading as an introduction to windowing systems, I find that a programming book's windowing section might be somewhat more beneficial in terms of understanding a windowing system then expanding it to the more general understanding of windowing systems. While I did find some tidbits interesting (the long network path of the X Windows system over network still amazes me, since one could anticipate at least some of the reactions of the user and preload them locally, with only the really vital things going back and forth; an example is menus), the high-level nature of this document made it difficult to appreciate. The one section I found somewhat useful was the section describing the communication between objects, as we'll be using Java for this project, and the various and sundry message-passing methods, such as passing up to the parent class. Another interesting tidbit I found to be useful were the "keyboard focus" and "mouse focus" events, especailly in regards to scrollbars. It makes sense that, should one "lose" the scrollbox while scrolling, the system should continue to scroll the window. However, the reaction of some X-Windows systems, especially those where the mouse is used as the only means of determining focus (the mouse must be over a window to have focus to that window), is a rather infuriating design choice, as other factors (such as moving things about on your desk, and subsequently your mouse) make one lose focus on the work upon which they are currently working.
Vijay Rudraraju - Oct 22, 2006 11:43:34 pm
I have a decent amount of experience programming UIs with the Flash development environment and the use of the event-driven model of interaction is something I have tended to take for granted. This article provided some very useful information about the thinking that went into the development of the event handling model. This model has turned out to be a very powerful way of designing UIs as most web development platforms implement this model in one way or another.
It appears that Flash uses a variation of the Windowing System Model very similar to Java in the sense that the entire .swf is downloaded by the user to their local machine, with the server-side providing information as needed. The use of client-side Javascript on the other hand as an alternative platform for web applications lies somewhere between Java and NeWs in the Windowing System Model hierarchy.
Simon Tan - Oct 23, 2006 12:21:43 am
Reading this reminded me of when I first used Visual Basic 6.0 to create a simple Windows application. Using Visual Studio (then and now) was all about event handling - coding what happens when users click on a button, or choose a menu option, etc. From the looks of it, this article is from the far past (the ancient Macintosh Finder, the mention of FORTH and NeWS, etc.) but the concepts introduced within apparently haven't changed that much.
It was nice to know that the double-click originated because of the Macintosh's limitations of a one-button mouse. Maybe if they had two or more buttons to begin with, a right-click would mean "open or get more information about" and the existence of double-clicking may have never come about...
Andrew Tran - Oct 23, 2006 01:03:19 am
After reading this article, i am overwhelm with all the information presented to me. I am wondering what was important from this article, what should i remember. I actually find this article to be quite interesting. I never knew how a computer handles a mouse click or windows being dragged and resized, now i know. I didn't even know that there are many different processes that handles different events, i thought the OS did everything for you. Some things in the reading were boring and the type that would make me ask "Why do i need to know this?" Such things were how it talks about how other systems handle events, such as the X system or NeXTSTEP. What was interesting though was to learn how Macs and Windows work. I didn't know it was pretty complex to handle 3 button mouse clicks and the keyboard. Maybe that is why Macs have always used the single button mouse for a long time, those were really annoying though.
Yimin Yao - Oct 23, 2006 01:35:34 am
As a frequent user interface user instead of a UI programmer, I have not really thought of the interface features at implementation level in such details. The article does give some good insights to the implementation of the user interfaces; for example, it helped me realize that the main program for a graphical application is usually minimal; a UI often times consists of initialization followed by a loop that gets events and dispatches them to the appropriate objects. Also, for a simple button, I've always considered the buttonClickedActioin, rather than the mouse down, mouse up, and special cases where mouse up is received while mouse down was outside of the buttom area. The problem with double clicking over the X server due to network delays is another interesting case.
I found the article pretty insightful although I do agree that in the attempt to be comprehensive and covering all the examples, the author had provided too much similar or seemingly repetitive examples that do not have visibly logical structure or clear message, which makes it hard to keep readers' attentions.
Chen Chang - Oct 23, 2006 02:50:57 am
I could never comprehend the complexity of a few mouse clicks or keyboard strokes before reading this chapter. This reading gave me a detailed critical analysis throughout and may have been too involved as it was hard to keep focused at times. I can definitely relate to the section talking about double clicking evolving from a limited macintosh functionality in a one-button mouse back in the days. With only one button, by default you can only click, click and drag, and finally release the button - not exactly enough for all the functions possible within an operating system. Double clicking adds many alternatives as the processor uses the timing intervals of multiple clicks to determine the desired action - commonly the first press down representing selection and the following click meaning the opening of an application. The complexity of keyboards are similar in nature due to different keys and input characters as you move across the globe, add that to the fact that you have a shift key which essentially "doubles" the amount of functionality your number of keys yield.
Antonis Mannaris - Oct 23, 2006 03:21:49 am
This was a very enlightning insight to the complexity of windowing based systems and other event driven interfaces. The history of these systems and the improvement they went through is amazing and given the fact that they now dominate other interface systems, it is extremely useful to see how they work. I was also intrigued by the huge number of problems that such systems must address. As a user you never think about the complexity behind a system which is so simple to use. As software developers we are extremely lucky that such technology is available to use, because if we had to start from scratch, our job would not be feasible. The chapter is really technical and low level for this class and our project (I hope!). However it is a useful start to event driven interfaces.
Eric Yoon - Oct 23, 2006 07:54:10 am
This article goes a lot more deeply into what goes on behind that most well-known of computer interfaces, windows applications. It made me reflect a bit upon how much more programming goes into a windows-type OS than a Unix one, simply because of the UI, in order to move scroll bars and windows and keep them nicely laid out and mobile. It's interesting that to your average user, many windows applications look the same (such as Mac OS, MS Windows or X Windows), but minor changes (the shift from a locally based program to a network based one) can cause substantial increases in complexity. Some of the solutions are quite innovative -- as in how NeWs, unlike X Windows, sends signals for the client application to draw, rather than sending pixel by pixel instructions on what to draw. Although I don't know Ajax all that well, my guess is that it works through a very similar principle -- that rather refreshing the web page every time something on the page looks different, it's able to send instructions to just alter a bit of the page, which allows someone to scroll maps on the fly and such.
Michael Mai - Oct 23, 2006 08:34:12 am
Here are the aspects of this article that I found interesting and worth discussing. Although the article does not expand on it, many computer operating systems now use the click-to-type key-dispatch algorithm. The concept of the key focus seems simple and may also be relatively simple to code in terms of event driven actions. This model was most likely incorporated in order for users to have full control of their systems using their choice of input device. Although it may seem difficult at first, the keyboard can and should be able to allow the user full access to the resources on a computer.
After reading over the abstract OOP class model, I was surprised that not all models were designed this way. Understandably, there would be a whole slew of classes and subclasses that would be created but I thought that that was how it was done. Looking back on it now, it would be relatively inefficient to do this but this model does make it easy for the user and a programmer to understand how everything works.
Overall, I liked how the article uses examples of MS Windows and MACs and such. It helps brings examples of systems we know to the forefront of our minds.
Yang Wang - Oct 23, 2006 09:57:25 am
I found the idea of event-driven GUI to be very interesting. But when I was reading it, it strikes me as more of an idea hten something to be done in real life. The article was very detailed in re-counting the story and give plenty of examples. I found them not very useful for system programming or even some applicational programming, but more for the web development.
From my working experience this, when I did worked as a web developer and programmed in Flash, the way this article addresses UI resembles what I see in the web development world, where all the code we are writing with Actionscript are completely event driven, there is no stream-line excution of code. I don't know whether that event-driven programming will be more popular in the future, but currently I can only see it apply in limited field.
Tabassum Khan - Oct 23, 2006 10:18:01 am
This article reinstate one of the reason to study User Interfaces that was mentioned in the first lecture of this course i.e. approximately 50% of the work for real programs goes into designing and implementing User Interfaces. In this article we learn about the thoughtful design and strong implementation that goes behind a simple mouse-click or a key-press. The complexity is greatly reduced by implementing these events in an organized architecture where each piece of the architecture has a relatively simple task to perform. The concept of interactive objects called widgets is very object-orienty because they share a common interface which does not require the tools working with widgets to know about their implementation.
Robert Held - Oct 23, 2006 10:18:37 am
The reading showed how much thought and effort must go into an intuitively-programmed user interface. I doubt many users appreciate the underlying code that allows them to simply click on buttons or drag icons to perform various operations. I thought it was nice that the article mentioned event-driven implementations in Mac, NeXT, and Windows operating systems. However, it always felt like it would begin to get into interesting details, then abruptly stop and move on to another topic. In particular, the complicated nature of pseudoevents, and how to program events to trigger each other, could have used more attention. It would be extremely useful to be given a methodical approach to implementing and organizing pseudoevents.
Johnathan Hawley - Oct 23, 2006 10:38:37 am
The reading was interesting and shed some light on aspects of event handling that I have never thought of and took for granted. It had never occurred to me that event handling was a vital to provide direct manipulation. I have never thought of moving and dragging files around in Windows was direct manipulation but it obviously is. The windowing system is something I've always taken for granted. It has always seemed to be such a natural way to navigate through an operating system but I suppose the leap from the command line to the windowing system can be thought of as quite revolutionary. The main event loop section was interesting. I was not aware of how much was going on under the hood in order to implement an event handled interface. I came across some of these different events regarding the mouse while working on HelloWorld, so it's good to have a practical example to refer to while learning these new concepts.
Scott Friedheim - Oct 23, 2006 10:49:27 am
This article was pretty basic GUI event models stuff that you would find in an intro to SWING book. However, I find great respect for the complexity of the GUI models. There is an enormous amount of layering and logic that goes into making a GUI application work. That is to say, more so a while back; now-a-days, as someone commented above, a GUI application can be coded in no time by just "filling in the blanks" in Visual Studio. But to code modern systems, even that is not enough; you must consider multithreading and it's implications within your own application, as well as handling all of the event handlers.
I would have appreciated this reading more if it had gone a bit deeper into how GUI applications interact over networks and with the underlying hardware. But I guess that is why there is an Operating Systems class.
Anirudh Vemprala - Oct 23, 2006 11:09:19 am
An interesting summary of techniques and models used in GUI programming. Though a lot of the systems (Mac classic?) and possibly techniques are antiquated, I guess the paradigms like the window hierarchy, window events, the event loop and event dispatching remain. It would be nice to see a discussion of some of the features in toolkits like Cocoa, QT or .NET with regards to UI development. Lets hope lecture covers that.
Joe Hart - Oct 23, 2006 11:15:03 am
The GUI interface is such a part of our modern day computer interaction that it really isn't thought about much in detail. I believe programmers today code this way (or at least I do) thinking it to be a normal standard way for a user to interact with your interface. Yes, many hours of thought must go into designing GUI interfaces but modern tools have made creating GUI's to be somewhat easier than it once was.
It will be interesting to see what GUI's change into once the method of user input/feedback is changed in the future. The event fdriven model and GUI's make sense when interacting with a computer through mouse and keyboard but some other type of model will be necessary when things move to mroe imersive environments.
Melissa Jiang - Oct 23, 2006 11:36:31 am
The article pointed out that running a system that is used to three button mouse on a system taht only assumes a one button mouse may be problematic. However, when running a Mac, quasimodes allow for a replication of what a type windows mouse do. With more modes, many of the different commands can be implemented possibly without too many qualms.
I am actually quite shocked at the amount of time and thought that must be put into making a mouse and the button down, button up events. I always thought the mouse was a simple item. Although, maybe that just goes to show that the more simple something seems to a user, the more thought was put into that interface or design.
Bryce Lee - Oct 23, 2006 11:44:17 am
The model view controller dominates most of modern program development applications, such as Visual Studio 2005 and Apple's Xcode. Both of these applications abstract away most details about window handling and commonly used interface objects (buttons) and focus the programmer on the event model. For example, double clicking on an interface object will bring up a code fragment area for you to write the event handler. Also, as the reading referred to, there is sections of the code to handle initialization of window elements on creation. I find this development model is very effective, since it breaks the programmer's tendency to think in algorithms and linear execution and instead focus on the actual interaction with the user.
Dexter Lau - Oct 23, 2006 11:59:23 am
While computer interfaces can be a number of things (a command line, a Anoto pen, etc), this article only articulates the nuances of actions and events that users can use with regards to windows. Most people are used to the traditional windows systems (e.g. Windows XP), but other windows systems can operate remotely such as X Windows and NeWS. In any case, there are basic events such as the operations a keyboard or mouse can provide and they must be dealt with accordingly. Actions in themselves can be objects with subclasses as well. The objects communicate amongst one another in order to create a program that is user friendly. The problem with even driven software is that there is no narration; every action is independent and free flowing, making programs hard to design and anticipate actions.
Roland Carlos - Oct 23, 2006 11:56:17 am
While I did like the fact we learned about differences between different systems (Windows, Mac, XWin, etc.) I felt like it interrupted the flow of the paper at times. Nonetheless, it is valuable to learn the differences so we know what are the standard(s) in place today (and know which way would be the best to apply to our own projects).
Yet again, it's another article describing all the important issues/complications we have to deal with something that we take for granted. But as usual, it does make sense after you've been able to digest it, windows, mouse clicks, they're all tricky issues that you have to figure out how you're going to deal with it. Your system can get very complicated depending on what programs are running, what parts are taking input, pushing output, etc. The key of any good interface is how well you can handle all these events in an elegant manner, at least elegant enough that the user doesn't notice any problems.
Sung Yi - Oct 23, 2006 12:22:55 pm
This article is very interesting in that most UIs are event-oriented. For the generic main program shown in Figure 4-7, the program is stuck in the while loop unless it is time to quit. One worry with this is that it might use too much of CPUs allocated. One the other side, it was very surprising to know the origin of the double-clicking system came from the one-button mouse system of Macintosh. One issue I want to mention here is that the difference in the unibutton and multibutton comes from the battle b/w simplicity and functionality; I use both Mac and Windows, but I still feel it's much more convenient to use two-button mouse rather than the macintosh mouse.
Heung Tai - Oct 23, 2006 12:14:55 pm
It is very clear that the X windows system is very inefficient because it requires network transfer for every event shot in a gui. The obvious solution is to make the event handled locally, like NeWs and java. However, I am not sure what the difference between two technique. It seems NeWs use intepreter but java use virtual machine to handle the event locally??
On the other side, I really learn a lot from the illustration that why graphical interface is much harder than text interface. It is due to the fact that graphical interface is event driven and the event is created by users, so users are in control compare to the text interface in which computer is in control. When a program has to deal with arbitrary user, it becomes much harder since the programmer has to predict what that user would try to do. I have heard that eighty percent of the code in a program is for handling user and now i really believe it.
Julius Cheng - Oct 23, 2006 12:23:32 pm
As a person who has had relatively little experience with programming compared to others in the class, and no significant experience programming applications, the event-driven programming model is something I have taken for granted through everyday computer use. This article had a lot of technical jargon and was packed with detailed information, but the parts that I did understand were quite illuminating. I'll definitely be re-reading this article throughout our interface project.
Michael Udaltsov - Oct 23, 2006 12:34:20 am
The article provides a good introduction to event handling, and how it's used in several operating systems (though somewhat outdated). It's interesting to see that even though the systems eventually perform the same tasks, their implementations are very different, for example in how event loops and event dispatching is done. These differences translate into the balance of control vs amount of code that the programmer has to write. When the programmer has to write less event handling code, he or she can focus on the functionality of the program, and leave the rest of the UI to the system to handle. Even though this reduces how much control the programmer may have over the system, it leads to more stable code, and a more uniform interface that uses the same components as the rest of the system.
I think that's one of the problems with Windows - they support several methods of handling events, drawing on the screen, and creating/using GUI elements, from the old C Windows API, to C++ and MFC, to the newest C#. This means that various software packages are vastly different in how they handle events and the user interface. Because of this a lot of software is inconsistent, and requires many additional libraries to run properly. This also means that Microsoft has to continue supporting all of those methods in newer versions of Windows, which brings all the old bugs and security flaws into the new systems as well. I think that they should at some point switch to a single simpler, more consistent model, and phase out older systems just like they did with DOS and 16-bit support during the transition from Windows 95/98 to 2000/XP.
Qingyun Tang - Oct 23, 2006 12:36:00 pm
It is interesting that the article has concluded regular graphical interfaces are organized in trees of windows. The communication among objects that cooperate to make up an interactive application is essential to understanding interactive software. To design better user inferfaces, we as UI deisngers must let user in control instead of letting user feel that the machine is acutally in control. The article goes very detail of implementing user interface, such as the problem with double clicking over the X server due to network delays. And the article talks about object-oriented event handling, which was different from what I previously thought.
Siyan Wang - Oct 23, 2006 12:45:52 pm
I found this reading a lot more technical than previous readings, and a fresh change to actually discuss the implementation of things, especially with our project deadlines coming up. However, although this reading was more technical, it contained very little code and its discussion seemed like it would be helpful to even a non-CS student, which I suppose is the appeal of this article. I found the comparisons between Mac, X, and Windows pretty interesting and it provided some insights into how to handle certain things, both from an implementation and a useabilit perspective.
Eric Vacca - Oct 23, 2006 12:25:08 pm
Moving away from text based programs to GUI's inherently caused a shift of control from the programmer to the user, making for more useful interfaces for the user, but a hard job for the designer. It was interesting reading about the architecture differences between the different OS' and the increased complexity that the designers implemented in order to achieve different functions. The keyboard/mouse focus was especially interesting to me. It always puzzled me in applications such as AIM when a window pops up, if the keyboard curser should be changed or not. Some applications override this mechanism while others don't. It turns out this isn't a overall physical "rule" in the OS, but specified by situations in the applications. For things such as keyboard and mouse focus, it could be useful to include some additional set of physical boundary rules so we don't have applications fighting for the users focus, and let the user decide.
Tom McClure - Oct 23, 2006 12:40:20 pm
I'm pretty familiar with event handling and window systems, having programmed UIs for MOTIF and XWindows as well as MS Windows and Java AWT & Swing, so most of this article was review for me. I did appreciate the argument against subclassing button objects, where the author recommended adding functionality on an instance basis rather than building an entire subclass for each different button -- ie, related to the different actions to be taken on clicking each different button. It's too easy sometimes to blindly map objects onto things where doing so results in obfuscation and difficult-to-manage code rather than taking a more simple approach. Sort of off-topic but this is one of my pet peeves. Objects have their place and utility, but the paradigm can be taken too far. Proper choice of object (and proper choice of metaphor, ie object name) is often crucial at the abstract level just as choice of metaphor for the user interface is key to the interface being understood.
Yen Pai - Oct 23, 2006 12:52:45 pm
Understanding how windowing systems work is great knowledge to have and I suppose the point of this reading is that UI designers must educate themselves with the platform for which they are designing. A good example from the article is how X does not naturally have features to support double-clicking. Keeping in mind the particular advantages and weaknesses of a given platform, designers must carefully pick a blend of features that not only come together to create a good UI, but also will work well for the target platform.
Sean Carr - Oct 23, 2006 12:50:16 pm
I had never heard of NeWS before, but it sounds really cool. Makes me wonder why everything I see still uses just X. Most of the rest of the article doesn't seem like that much new though. It goes over all the standard ways to do event handling. The descriptions of the OS event handlers were something I hadn't really had in detail before, but the program level descriptions of mouse and keyboard input handlers described the tools that people are already familiar with if they have programmed user interfaces before. This could act as a good preliminary reference though if a programmer is unsure how to fit all the pieces of their UI together with the system. Beyond that though it is usually more usefull to look at langauge specific event handling documentation.
Kimberly Lau - Oct 23, 2006 12:53:31 pm
This article was extremely technical, but still stimulating enough to engage me (as someone unfamiliar with intense programming). It was interesting to read the comparisons between systems/functions, and was a nice introduction to event handling, as much material in this class is new to me. I would need to read over to fully grasp all concepts described here.
Siu Pang Chu - Oct 23, 2006 12:59:43 pm
This is the first article is interesting for me since this is my first reading about event handling. This article discuss how events being porcess as the communication between the user and the machine. The author used a tree sturcutre to respesent a the events of windows. When the user made a inout, it run thought a system to determine which window should reveive this event. Then, the article talk about two event handling system , X and NeWS. It is difficult to give 10 different choice of actions on a single input device with only one or even three buttons. So we solve this problem by providing special-function keys and double-clicking, like the apple key ,shift and contorl button.
Jason Lee - Oct 23, 2006 12:40:43 pm
One of the more interesting aspects of the article to me was the discussion of the fact that different systems are configured to different hardware configurations, which may cause some inability to perform some operations correctly. Specifically, it was interesting to read about the fact that the Macintosh tool box automatically assumes that there is only 1 button, while Unix systems assume that there is 3, and so using Unix programs on a Macintosh system can be very problematic. It's interesting to think about the fact that hardware configurations across different platforms must be taken into account when designing programs and GUIs. there are not many applications that exclusively require active use of all 3 buttons, as most Unix programs can be operated fairly efficiently with only 2. However, for complete functionality, it would be difficult indeed for a Mac user to run Unix programs through X. This may be something that needs to be considered while designing our project for the semester.
Jae Chang - Oct 23, 2006 12:58:38 pm
This article tells us how event handler works in computer systems. Event handling is crucial part in UI program because the event handling provides better interaction between computer and human, and Windowing system is one of the representatives of the event driven application for GUI. As the author mentioned, if Window system does not exist, then direct manipulation cannot be achieved. Also, the main event loop reminds me Microsoft Visual Studio 6.0 and MFC. After reading the explanation of remote windows system such as X Windows and NeWs, I understood why such applications have bad respond time when internet connection is not fast; send signals of events and draw it on client system. The UI programming using object connection model was very interesting.
Edward Karuna - Oct 23, 2006 12:56:29 pm
This reading made me think about the many exotic hotkeys that I have mapped on my computer. For example, I have defined Ctrl+Alt+Shift+T to open a prompt to open an SSH window, and Ctrl+Alt+Win+N to open a notepad window if none is already open, or bring it to the front if an instance already exists. I always took modifier keys for granted, but I have just now realized how much variance in modifier key quantity developers have to take into account. It also demonstrated to me how much my normal computer operation depends on chording.
Jason Shangkuan - Oct 23, 2006 02:19:05 pm
Comment 1:
It is interesting to look at the outlines of event-handling for certain applications because every action can be considered a state. For each high level state then there can be other sub-states that can branch from it. The state diagram and outlines provide a baseline to design around and how to utilize the states to make a UI. This is eviden in the evolution of UI's such as in Mac's OS, NeWS, Motif, and Windows. All these programs demonstrate a different repesentation on how to implement such diagrams, where some are clear and others are convoluted.
Comment 2:
To add to my previous comment about states, widgets also can be modelled and represented by a hierarchy diagram because each widget action can control a different state. The event diagram and widget hierarchy demonstrate the importance of abstracting to a simple diagram to create a model of user interactions. For example, event types, sources, timestamps, and modifiers can be considered. It is interesting though that these are called events, but in some cases a few of these items can be considered modes. As a mode, they can be considered in making state diagrams, and from there, a designer can abstract an interface.
Huangnankun - Oct 23, 2006 12:33:29 pm
The MVC model consist of the Model, the View and the controller. In this reading, we get an overview of these components. The article starts off by going over the View, which is tailored to interact with the users. Since most GUI these days use a windowing system, which breaks down the workspace into independent components, the article first introduces this. The windowing manager is the program that takes care of the windowing system and there are many types of windowing sytem software, such as the local systems in Mac OSX and MS Windows and networked systems such as X windows.
Next up in the MVC model is the controller, which takes care of the interaction between model and the view. The interaction with the View ( windows ) is done Via Events, which are software routines that are raised whenever a specifiecd action is performed. These events are broken down into mouse, keyboard and windowing events. Events are dispatched as messages and this is done through the event loop. Its interesting to note that in modern programs, the main event loop is usually made transparent via the API. In the old days of windows programming, I remember having to define these myself with the WIn32 API ( not MFC ). The article then goes on to talk about the various event handling mechanism in the different operating systems.
Rayhan Lal - Oct 25, 2006 03:51:41 am
(Post 1) Olsen does a wonderful job describing the perils and promise of event handling. I especially like how he caters to those who have not worked with event-based GUIs before. I absolutely agree with Vahe, I HATE mouse-based dispatch because there is just too much chance the mouse will move. When checking a help topic or entering text in a similarly small box my pointer always manages to slide out at the most inopportune time. The optimizations discussed towards the end of the chapter are quite useful but I still feel (intuitively) like there are easier ways to handle events.
(Post 2) It is clear from the article that NeXTSTEP provides a seamless windowing system that makes dispatching events transparent. I invite the reader to have a look at this promotional demo: [1] illustrating just how powerful and ahead of its time NeXT was. The interface builder and database toolkit described are more efficient than the methods we are using today! As a side note many people mentioned their previous experience with RAD packages, but one must remember what is saved in time is given up in customization. The article is a good reminder that we as programmers have control over every single event that occurs within our window.
Utsav Shah - Oct 28, 2006 05:53:38 pm
Though long, the reading was very informative and important in order to implement a “good” graphical user interface. I like how Olsen touches on every single detail of windowing systems and its complexities. As many others, I was also fascinated by some of the event handling mechanisms. The scroll bar example in particular was very interesting. It was also great to learn about different event dispatching models. Information on object oriented event handling was also very useful since many programmers use object oriented languages. The example uses of Windows, Macintosh, X, and other systems also provided great insight to understand the event handling well.
One thing I learned in this class is that one needs to pay attention to nitty-gritty details of UI as one would do with software. After reading this article, I realized how much hard work and details go into designing a good user interface. It all looks standard and easy to use but there’s lot going on underneath in order to provide that ease for the users. After working on the projects and reading these articles, I realized that even user interface designs need as much detailed work as softwares.
David Eitan Poll - Oct 30, 2006 08:14:15 am
The Model View Controller architecture can be particularly effective, especially when compared to other less organized approaches. I've been making extensive use of this strategy with our interactive prototype, and it has changed the way that I think about interactions between the UI and business logic/data (ever since I first learned of this during an internship). The model provides a powerful tool for managing and coordinating requests that stem from anywhere within the UI. Otherwise, the system can get convoluted with data that can be accessed in some parts of the system and not in others, etc.
I've always been impressed by Event Driven UI. It's a really powerful tool, and can be harnessed for non-UI concepts as well (especially for communication between multiple threads). Handling UI input could conceivably be very difficult, and I wouldn't want to be the one who has to decide where interactions should be processed. Dealing with the complex nature of the UI heirarchies that one can build would be terribly difficult, and Event handling really goes far to simplify that process, providing a model through which input can be captured and dealt with. In swing (and I think even moreso in .NET and Windows Forms), the pub-sub (publish/subscribe) system for event handling is a very effective way to produce predictable behavior from a complex UI.
Aleksandr (Sasha) Ashpis - Oct 30, 2006 09:57:50 am
1) Although I would never give up the GUI to go back to command line, the reading is strongly implying that it is much easier, from the programmer and computer points of view. If this is the case, which I agree with, why haven’t GUI’s been properly abstracted from the command line, meaning why do so many more errors occur? This is meant to be more a rhetorical question, and/or food for thought. It is amazing to me how certain things stick, even though there is no good reason for it, for example the double click on a mouse. For a new user it is hard to understand when and where to double click because there is no inherent guidance for the user. In addition, older users have difficulty double clicking fast enough and take a long time to adapt, which is a big negative in spreading computers to more and more users. I have actually run into this myself, when teaching my grandfather to use a computer, although he was frustrated and almost gave up; his desire to use the internet outweighed the difficulty of learning tasks
2) Continuing with window events, will the mouse ever be replaced? Meaning, will something better come along? The question many smart people have and do ponder is how to make the user more productive. This is especially important in the business setting. The ultimate future in my opinion would be the computer recognizing a users brain ways, like an MRI or and EEG and reacting properly to them. This sounds great merely from a technical challenge to accomplish, but then do we really want machines to be able to pick up our every thought? Just wait and people think we have no privacy now!
Jonathan Chang - Oct 30, 2006 12:16:14 pm
Event Driven UI is a powerful concept, not only in terms of local applications but also web applications, where events originating from the user is the only thing that brings about change. While this is probably just an archetype of my long-time use of GUIs and event driven interfaces, I feel more comfortable and in control when I can see my physical actions taking effect, the gulf of execution right? I do remember command line DOS prompts back in the day, and the always made me worried that I would feed the computer something bad.
This is definitely a very technical and very very long article, so I'll be honest and say I skimmed it pretty quickly. However, I definitely plan to go back and read it more in depth when I have more time, because so much of this is relevant. While working with Swing on our Interactive Prototype, one member of my group remarked that he really felt like he was making an application for the first time. That's because in current industry, everything is GUI and everything is event driven, there's just no other way to do it, and no way to market yourself without skills in it.
CharlesLeung - Oct 30, 2006 11:56:32 am
This reading was very interesting from my perspective because I do not have much experience with GUI design. In fact the passage about the main function and how it differs from normal main functions was actually very important for me. I remember my first experience with a program with a GUI and I looked at it's main funciton and was very, very confused with what it's purpose was. I think this is something important to keep in mind for the beginner.
I really like the idea of the event driven UI because it seems natural to design things around actions that the user makes and then have the program respond to those actions. The event driven UI really simplifies things for a programmer who may be intimidated when created their first GUI. My recent experience with swing UI and the event driven interface makes me a believer.
Charles Lee - Oct 30, 2006 12:30:22 pm
1.) GUI's can be useful for ease-of-use, but a simple examination of Fitt's Law shows that keystrokes are definitely faster than mouse movements to experienced users. I often prefer keyboard shortcuts to GUI buttons. Moreover, user interfaces often hide features for the sake of preserving visual landscape and not confusing new users. Basically, UI's are great for quickly learning an app, but not always the best choice for frequent users of an app with many features.
2.) This reading was a lot more technical than the others, but it was still interesting to me. The event-driven model is an effective way of allowing the user to manipulate an application. This places more burden on the programmer rather than the user learning to work their program, but that brings applications to a more widespread audience, which is profitable, and thus is the standard. Also, objects are useful to use, but this article seems a bit strict about their usage.
Cheng-Lun Yang - Dec 07, 2006 04:01:19 pm
1.From this article, I learned that simple changes can affect the performance in a huge way. Running xterms remotely through SSH is a pain for most people. The scrolling movement is sometimes slow and lagging. It is due to the fact that the command needs to be transferred through network. When running the same command on local window does not lag like xterm window does.
2.After reading the article, I feel the design of windows application is the model we should follow, easy to use yet addresses many different aspect of HCI. Everyone who knows how to use a computer experienced windows application some time in their lives. It has become a synonym to computer. The complexity of underlying code further enforced the idea of user interface design, simplicity to the users.
Keenahn Jung - Dec 08, 2006 09:12:11 am
I very much like the idea of having a GUI that is functionally equivalent to a command line interface. That is, the GUI provides no more nor less functionality than a command line interface, and a user can accomplish all the same tasks using the GUI as using a command line interface. The command line interface is a powerful and efficient tool, once you learn it. The windowed GUI is easier for beginners to grasp, and is thus more natural, but both should be available. Most user applications today have redundant keyboard commands such that the mouse really is not necessary. This is great and can improve efficiency for power users as well as an easy interface for novices,
The Event Driven Model is a good model, and after seeing it, I really cannot think of any other model to use that is superior for interactive programs. Events should be the "primary communication vehicle" in interactive programs. However, it is not a good fit for other non UI applications. For example, while working on a group project and communicating via email, I am not going to poll my group members every five minutes to see if they have any questions, I will wait for them to email me. Furthermore, I will probably wait for several emails to pass before I check my email, then read them all at once. Thus, my algorithm for checking email is much more like "batch programming" rather than "event driven." Both have their uses, but event driven is definitely superior for interactive UI's.
Robin Franco - Dec 15, 2006 12:23:06 pm
Comment 1: Event-driven UI is something that came from a necessity, as describe in the article. With new interfaces, the programs had to be able to react to various events created by the user, on the user's own accord. I think this new way of programming is actually more intuitive than regular method of programming. As we start listening more and more to users, not only do designs improve, but so do methods used to create those designs. In the beginning with the use of assembly languages, it would be difficult to see how one could program any other way. But now we see that object-oriented languages, and higher-level languages are much more efficient ways of programing. I can see how an old-timer could be appalled by the fact that some languages such as Java and Python don't even have a way of directly accessing memory locations, which is what almost all of assembly is based on.
Comment 2: Originally when I was learning web development, I decided to start from scratch. I didn't split it up into the model-view-controller paradigm. I found that, as expected, it was more difficult for me to create and modify such an application. When I moved on to using other more sophisticated web frameworks such as Ruby on Rails or Turbogears, I gained a new found appreciation for their use of the model view controller.
