Model View Controller and Event Driven UI in Flash/Flex
From CS160 User Interfaces Sp09
Lecture on Feb 23, 2009
Readings
- Basics of Event Handling. Developing User Interfaces. Chap 4. Olsen.
Rohan Dhaimade - Feb 20, 2009 08:46:44 pm
This article is a bit old. Especially since it actually talks about NextStep and not OSX. Either way, the entire article was quite interesting as it explains all the details of the UI system. The UI model of having object that communicate with classes is genius. What I wonder is though is how this relates to interpreted languages such as Javascript. I know Javascript has the DOM which basically handles all the mouse/keyboard events on the browser but I wonder if it creates an interface that sends commands to the Browser that would handle the commands themselves. I know that Javascript DOM has all the things described as the OOP model of Window Management, but relates to each object inside the program and not just "Windows". One curious thing is that I wonder how how Windows handles the "root window", since each window is its own program and there are many programs that can generate multiple windows. Once a window closes, does the root window of an application change? Is there even a root window in Windows? The situation in MAC OSX also differs as there is no "root window" since you can have an application open without a window. You can then click immediately on the desktop if there is no window on it. So would there be multiple root windows per application or something? I'm just kinda confused on the structure of the trees when it comes with running applications.
Saung Li - Feb 20, 2009 08:36:42 pm
I thought the reading was interesting in that it introduced us to the concept of windows and windows management. Using a tree structure to organize the windows seems to be the easiest way to organize content to be presented to the user in the graphical user interface. Now I see that the MS name Windows probably came from this windows-based interface. Events such as mouse clicking, modifiers, double-clicking, function buttons, mouse movement, and keyboard events all act as input events to the system that must be dispatched to the appropriate windows to make the proper procedure calls. The reading on this seems straightforward but actually coding all of this seems to be very complicated. It is interesting how the main event loop is so short since one would expect it to control most of the windows and events. It just passes the calls to system calls that handles everything. To complicate things more, certain events need to be filtered out. The key event sequence "ctrl+c" needs to be filtered out and replaced by an event that indicates copying. Implementing network systems like X seems to be the hardest because the programmer needs to take into account possible network traffic that can produce lag on the user's display screen since the server is presumably located away from the user. In regards to key dispatching, I think the click to type model, the one currently used, is the best since you click on the window you want to type in and it shouldn't matter if you move your mouse away (maybe on accident). Using object-oriented programming seems to be a nice way of dealing with event handling. The same methods of the abstract class can be changed according to the application to carry out different functions, and subclasses can have code that overwrites parent classes while maintaining code from the parent class to use. Treating everything as objects that communicate with each other seems to be an interesting concept but hard to implement if not using the right programming languages. The widgets would have to have pointers to all other widgets that it can communicate with and one object can be receiving too many messages. The old article mentions several programming languages used for event driven UI. Could this system be more easily and efficiently implemented by any of the newer languages?
David Burban - Feb 21, 2009 09:33:09 pm
This was an interesting article to read, no doubt. It gives me a clearer view of how Windows API work. From what I understand now, Windows will broadcast all of the events to open windows. If the window has an EventHandlers for that specific broadcast, it will trap it. To continue the broadcast, the program's EventHandler must also say inherited, otherwise programs further down the queue stack will not receive the call. This is how I was able to intercept the USB disconnect functions in one of my applications, by just dropping an aptly named EventHandler into my form's code. The interesting part was when the application was never shown, and thus never registered, it would not receive such calls.
Kevin Huey - Feb 21, 2009 11:10:20 pm
This article is slightly more interesting than those in recent memory, though it does sound a bit old. My main confusion is the root window. Each window is found in a hierarchy of other windows and has some association with at least one object or program. They communicate with each other or send special information based on the user input and mouse position. But the root window has no such upward association. So how does it work, if there is one? Wait, the current systems do have root windows, right? The root would be the background screen, which nowadays usually has some customizable picture. Every other window goes on top of the background, which stays at the top of the hierarchy. New windows are added as subwindows in a tree. So I think it does make sense to me, if this is true. Not exactly sure what constitutes a top-level window though.
An aside: I don't quite agree with the reason for a hierarchy of nested rectangles on Page 3. Wouldn't any uniform (circle, oval, diamond, etc.) shape have the same effect? Granted, these other shapes would be unoptimized in using space within the window, but nesting them shouldn't be any worse than nesting rectangles when trying to get from one window to the next.
Prahalika Reddy - Feb 22, 2009 05:24:13 am
Although the article was interesting and a bit different from what we've been reading, the length definitely made me lose focus a couple of times. The section on Window Events reminded me a lot of the readings I've done before on Java applets, describing the keyboard events and mouse events. I was surprised to see how similar the two concepts are. The section on Main Event Loops was slightly confusing, I really didn't understand the part about Filtering Input Events. The only subsection there that I understood was the How to Quit part. In the section on Event Dispatching, I wasn't sure I understood the difference between the "bottom-first" and "top-down" approaches. It seemed like both options would get the event to the "Untitled1" window. The last section on Communication between Objects was also quite interesting, and it seemed that all the topics discussed before just get more complicated when dealing with multiple windows and the interactions between them.
Sean Hansen - Feb 22, 2009 05:14:08 pm
I didn't find this reading particularly interesting for a couple reasons: A. a lot of it was covered in a Visual Basic class I took a while back, and B. it had too much detail, which doesn't interest me until I actually want to effect something. That being said, it will be quite useful when I actually do start coding.
I like the idea of putting instances of applications inside other applications, though, particularly as it applies to games. Some games need to incorporate entirely disparate elements into their features (EVE online had a web browser and a music player), and it'd be a great relief not to have to make original applications in order to accomplish tasks that someone else has done better. In particular, many games suffer from very basic voice chat systems, and being able to simply port in more dedicated applications would work out better for everyone.
I guess what I should be saying is, are there any other readings on this particular idea?
Chris Thompson - Feb 22, 2009 07:48:57 pm
The first part of the article discusses a few various windowing systems. It explains how simple ones, like X, can manage any application across a network by sending events between the client and server which tell the server what to do and the client what to draw. NeWS takes this a little further, by sending PostScritpt code, which is executed on the client side and increases functionality while decreasing network cost. Java goes even further, and sends entire applications over as applets, only performing network communication when necessary. The second part of the article talks about window events, such as handling mouse downs and mouse ups on specific windows, as well as how they can be affected by modifiers. At this point, however, the article starts to drag on. It details all kinds of slightly different events, which are technically different but don't seem significant enough to bear repeating except for their historical details. But they essentially serve to make the point that pretty much everything that can be done can be controlled via events. The third section begins to talk about how event driven programs are structured -- about how a main loop continually checks for events to happen, and as soon as some do, adds them to the event queue for processing. Again, the article drags on here -- I'm sure the information is useful for one comparing the handling mechanisms of different existing architectures, but it seems a bit much for anyone intending to work on a single, practical system.
Jeffrey Patzer - Feb 22, 2009 07:39:52 pm
I thought this reading was way too detailed. It would have been much more effective were it a presentation of concepts and then details were given with relevant examples. When an article rambles along for a page talking about code that I can't see, then it gets a little confusing and hard to follow. Plus what really made it difficult, and from some of the comments above I think this was a big problem, the article focused too much on the details and not enough on explaining the concepts. It seemed that one sentence of explanation and then two paragraphs of implementation was how the author attempted to explain it to the reader. However, this made it actually too difficult to follow what was going on. All the concepts introduced though were very interesting and I enjoyed reading about them, it just became to hard to follow after a while.
Mark Dhillon - Feb 22, 2009 07:50:55 pm
One thing that I appreciated about this reading was that it gave some nitty-gritty details of different windowing systems. While I do think that a strictly conceptual layout would be more appropriate (because it is more versatile over time), a more focused and real-world approach is good too. Nothing in here seemed terribly revolutionary, moreover this seemed like a reading on how the windowing systems works in operating systems from back in the day. If you've taken an Operating Systems class, the event-driven architecture is nothing new (reminds me of interrupt-driven architecture). I can see this being useful for people who are new to computer science.
Alan Young - Feb 22, 2009 05:45:21 pm
Olsen's "Basics of Event Handling" is a very comprehensive article about windowing systems. The author goes into elaborate detail over some aspects that I felt were unnecessary but that may be because the article is old. For example, he spends almost half a page describing mouse button events and he spent a lot of time talking about keyboard events when he could have succinctly just said that key press corresponds to an event. However, one point about how X Windows did not incorporate double clicking until the Macintosh influence became strong was interesting and I think it's true that different window systems that exist currently have converged more than they have diverged. An example of that is how the new Windows 7 interface is very similar to the Mac OSX interface and the gnome desktop for Unix/Linux has always been modeled after OSX. I think that this article provided a good balance between high-level descriptions and specific implementation details that makes it clearer to understand the different event-handling systems. Even though the examples are outdated and show old technologies used, I can see how current use of rich media such as online flash interfaces may be implemented similar to X Windows so the principles seem scalable.
Timothy Yung - Feb 22, 2009 08:28:30 pm
I found this article to be interesting, but it could have been much more if it were updated. The article makes good uses of examples from old systems, but some of the design considerations at the time do not apply with today's technology. For example, the idea of redrawing hidden portions of windows has, since Windows's Aero GUI Manager, been tossed out the door in favor of storing all the bitmaps in memory.
It was very easy for me to grasp the concepts introduced in this article because I have dealt heavily with the event propagation model used in modern web browsers. This also made the article more interesting because I was able to identify why certain design choices in the browser even propagation model were made and it allowed me to critique the different models provided in the article with a better idea of what works and what doesn't.
Besides being outdated, my other gripe is that this article was way too long.
Jason Lo - Feb 22, 2009 08:00:36 pm
I agree with people who thought the reading was too long or along those lines. It seemed to me that the article should focus more on the concepts, rather than each of the individual implementations. It should talk more about how the system is designed, general concepts all the systems follow. I would be interested in hearing about the X windows implementation, but that has left to do with GUI and more to do with networking. I don't think the tree ideas were explained too well either.
Shoeb Omar - Feb 22, 2009 10:07:09 pm
This article was quite frustrating to read because all of the material was dated and much of the concepts were common sense. Those that weren't all that straightforward weren't explained very well and the attention to detail was frustrating also. I liked that they included plenty of figures and diagrams to try and explain what they were talking about but for this kind of article, it feels like a waste of time to read something so dated. I feel like I would have been excited and into the reading if it was about the things that I use over and over again today. That way I could really see what's going on under the hood of the windowing interfaces I use today rather than its predecessors.
Furthermore, I just started reading through the comments posted and I think Chris basically summarized the entire point of the article in a nice brief paragraph. Very succinct and covers pretty much everything important in the reading.
Nalditya Kusuma - Feb 22, 2009 10:22:35 pm
The reading is pretty interesting coz i have not been exposed to UI programming a lot. It starts by explaining the back-end of X window system which I did not even know--and I understand now why the boxes for Soda Hall's 2nd floor computers are so small coz everything is handled by the server :) Other than that, i like the way the reading points out the common events one by one and explains what each does. I think this reading is going to be important for the programming assignment.
Denise Ngai - Feb 23, 2009 12:37:12 am
This articles does seem pretty old, considering the images that were presented and the OSes that are discussed. The topic is pretty different compared to what we've been doing lately. It seems the articles we have been reading concern general UI design and things to keep in mind regarding the user. This article, however, concentrates on OS UI, the actions that are taken to use certain functions, and how the computer handles these actions (events). This reading also gives more of a look at the back-end processes behind the design, such as in the "Dispatching Events by the Windowing System," where they actually show code along with a description of what it does.
Yin-Zen "Johnny" Hwang - Feb 23, 2009 12:54:56 am
although reading thsi article is like reading into the past that is still trying to explain in words what Apple brought to the world in 1984, this reading does more than that by going into the OS to explain how a windowing system is built. w00h00, something i haven't learned before yet. awesome.
ah. X system. so that's where xLib comes from. there's another app for the TI-83+ family that goes by the name of xLiB. probably taken from that.
but Java lags =(( eek. why does Apple have to be so annoying with their single button? omg just conform already.
by the looks of it though, programming windowing is pretty much just OOP.
William Cho - Feb 23, 2009 01:20:59 am
It sure seems like a lot of work to implement an event-driven GUI architecture and manage windows, as opposed to the simple command line interfaces where the system, not the user, is in control. But I'm grateful for all the work past programmers have done. Here I am, many years later, happily conditioned to using the Windows OS and manipulating windows in various ways; it's a stark contrast to command-line interfaces like MS-DOS, at the very least. I wonder how much of event-driven UI design has changed since this article was written. I also wonder what else GUIs can be constructed upon; the article mentioned that GUIs are "generally built on top of a windowing system." But I can't really think of any other GUI design off the top of my head that does not use a windowing system.
Bernardo de Seabra - Feb 23, 2009 01:43:58 am
I classify the reading "Basic of Event Handling" as interesting material but is far from worth the time I had to spend reading it. I believe the same concepts could be shared in a much more succinct fashion. Having vented my frustration with the length of the reading, I would like to highlight a few important aspects. It was interesting to read about different approaches used for managing a windowing system and their pros and cons as well as their evolution. In addition, I enjoyed learning about the specificity of the constraints for the X Windows system while operating through a network connection. I've exported the X Windows screens to remote machines before but never noticed how complex it could be to synchronize events. In terms of event dispatching I was not surprised with the approach as it's quite common for any object-oriented system (as any CS61A student knows since it's well covered in the class). Overall, although a lengthy reading it covered interesting behind the scenes mechanisms that make graphical user interfaces a reality.
Joseph Tsay - Feb 23, 2009 01:41:17 am
I felt that this article, although lengthy and outdated, contained useful and interesting information about the evolution of the ways events are handled. I found the information on the client-server backend of the X window system particularly interesting. I felt that it was a little too detailed and many times I started to lose interest.
Timofey Titov - Feb 23, 2009 01:40:12 am
It's surprising that the author views the network feature of X Windows as a drawback. After all, this is more of an extended capability compared to desktop windowing systems, and thus brings with itself difficulties.
Among hidden elements under the hood of OOP are message dispatch and scheduling. Besides providing the capability of objects for Direct Manipulation interfaces these features allow even better mapping, so that the programmer is able to implement interfaces conveniently. We can see again how OOP and Direct Manipulation go together. I understand now why OOP became so popular, because it addressed the problem of programming a myriad of events.
The author goes as far as identifying conversational models of interface to be under program control. I have to disagree with that. The format is more strict/limited, but things like the Unix shell can in fact give the user more freedom in terms of functionality.
Chunwei Lai - Feb 23, 2009 01:52:48 am
Like many others who pointed out the length and relevance to current architecture, I too feel that better examples could be given with modern examples even if some of the concepts are still the underlying model for systems nowadays. It is understandable how OOP can be the direction for programming between GUI since interface is meant to be uniform and OOP can allow one to easily achieve the same interface. Each object (scroll bar, text window, etc) in a window needs to be able to communicate with other objects of same or different windows and the reasoning behind event-driven seems very well-thought out. I particularly liked the discussion of windowing system among the different OS.
Dwij Garg - Feb 23, 2009 02:01:32 am
I agree with most people on this discussion about this article being old, boring to read, and almost seemingly useless. However, I found it really interesting to read about the various Windowing System Models. It was interesting to read about how we have gone from the X window system, to the NeWS system, and now finally to the Java based system. However, I do not know if this is the end of the line, or if there have been other improvements in this management system (as this article is old). I also like the fact that this article is based entirely on the Mac OS!!
Sean Ahrens - Feb 23, 2009 02:24:54 am
I found this article overly detailed for the purposes of our understanding -- and without endless hours meticulously reading and notetaking on it, I basically just got out that input-handling varies across machines and frameworks and that windows, event handlers, and events are the main objects of action. They interact in a variety of ways, and communication (notification) between them is a crucial issue. Other than that, there is not much for me to agree, disagree, or otherwise debate about this article -- it's pretty much just straightforward stuff. I guess I can say that javascript provides a good modern, webby example for how event listeners and handlers are used: with its onClick, onFocus events, and the like.
Adam Kauk - Feb 23, 2009 02:49:24 am
A big picture lesson we can take from this reading is that in order to advance the field, you often need to do things radically different, like event based UIs. Brave moves like that are ones that make a big impact in the long run, even if they are a bit more likely to fail in the short run.
Victor Lum - Feb 23, 2009 02:58:41 am
This article was long, and really detailed. It seemed to go through a step-by-step process of what happens when, well, any event happens. Although it was kind of hard to read through, it was kind of interesting to learn what exactly happens when you click something, or something like that. But I think it would have been a bit more useful (and easier to read) if the author was more conceptual instead of describing the actual implementations, although that's useful too.
Alexei Baboulevitch - Feb 23, 2009 02:35:28 am
The detailing of the inner workings of the default Windows interface (which is mostly shared with the actual implementations described) was particularly illuminating. The default widgets like the corner buttons and scroll bar are so prevalent that it's very difficult to consider their workings individually. I also found it fascinating how the windowing system can be disassembled into discrete components and managed over a network. It's easy to forget that the Windows interface isn't the applications themselves, but more of a standard GUI -- tools and methods that can be used to manipulate and transmit data. The fact that this can be networked indicates just how low-level many applications are, even if they're highly visual.
Cuong Ngo - Feb 23, 2009 03:14:58 am
This chapter turned out to be a pretty good read even though it was fairly long and somewhat dated. Specifically, I see how operating systems handle events differently due to the hardware configuration they support. For example, Microsoft Windows defines three separate events for the left, right and middle buttons of a 3-button mouse whereas earlier versions of Mac OS supported 1-button mouse only. The chapter also explained what goes on behind the scene when events are triggered and handled. For instance, some systems like the Macintosh and X place events are on a queue and the "main event loop" removes and dispatches them for processing. An interface won't be complete without event handling, and a good interface is supposed to handle events smoothly in order to improve user experience.
Sean Kim - Feb 23, 2009 03:19:07 am
After the user, not the program, is in control such as direct manipulation, the communication between user and machine is getting complicated. There are interactive objects as a representative for a user and input/output system as one for a machine. As the relationship is required more complexity and functionality, the new technique have been developed. The most useful and popular one is using with windows. It is implemented with lots of events that user can make/act. Therefore, each action of user can be signified for generating more efficient result for solving the relationship between the user and the system.
Moonway Lin - Feb 23, 2009 03:29:48 am
Having seen a bit of JavaScript programming, I can relate it to the article's thorough discussion of event handlers. The JavaScript language features many useful event-handling functions such as
- onClick invokes JavaScript after a mouse click
- onLoad invokes JavaScript after a page finishes loading
- onMouseOver invokes JavaScript after a mouse hovers over a hyperlink
- onUnload invokes JavaScript right after someone leaves a webpage
Of course, for a fully-featured operating system like Windows or MacOS, the event handlers are far more numerous and complex. But they all operate under the same fundamental principle, which is processing application-level information from an underlying framework. And of course, the most necessary ones related to clicking, loading, and key-pressing are common to all environments.
Phiroath Chan - Feb 23, 2009 03:32:26 am
I thought the introduction talking about the the difference between a control architecture and a direct manipulation architecture was a great intro to the paper. With control architecture the program is in control while as with direct manipulation architecture the user is in control. The benefit of control architecture is that it is less complicated than the direct manipulation architecture. The program has a set of things that it can do and the user can ask the program to do only those things, but in a direct manipulation standpoint the user program is the one doing what the user wants and that can add a whole another layer of complexity.
I thought the paper was pointless at some points in the paper. It is true that if u ask a person to describe a windowing system the logical response would be "what do u mean", but after reading a little further into the paper the definitions are quite easy to understand. I don't mean the details of how a windowing system works is common sense or anything, but the concept of direct manipulation is quite common sense. People now are using computers, opening and clicking on applications, and resizing windows so often now they will get the concept of direct manipulation pretty well. Granted that they will probably don't know that what they're doing is called direct manipulation, they still perform direct manipulation tasks.
The paper does provide some good details though from a programming point of view. User interfaces are built upon small fragments and coders apply code for these small fragments. Together the fragments will make a graphic user interface.
Derek Liu - Feb 23, 2009 04:17:11 am
This article is indeed, as pointed out in earlier posts, a bit outdated. However, it was an interesting read for me and provides some background on the evolution of operating systems and their interfaces. The distinction made between mouse events in Macs, Windows, and an X-server were particularly interesting, most notable the running UNIX from a Mac through an X-server and the numerous problems that could cause (I still wonder what was mac thinking when they created only one button mouses?). I felt the article did a good job moving between lower level concepts and higher level concepts as far as windowing and events, distinguishing between the programming side of even key down and up and what to do, and the user side of interacting with the guis.
Chang Su - Feb 23, 2009 04:04:20 am
Engineers and scientists often suffer from poor writership. Computer scientists, being a combination of both, perhaps suffer twice as much. What useful information contained within the article is largely lost in the author's verbosity. He spent pages after pages describing basic IO functions that any child growing up in the 90s would know like the Pope knows his Bible. Only halfway through this drudgery did the author begin to reveal some real, behind-the-screen tricks. But again, most of these are lost to his rattling off one language after another, one system after the next. Ultimately I wouldn't say I derived nothing out of this reading, but wrenching a fresh salmon out of the paws of a grizzly bear might be a simpler task.
Stephanie Shih - Feb 23, 2009 03:21:55 am
The reading was interesting to me in that it presented new ways of looking at how a UI interacts - i.e, the window tree algorithm. I actually found the level of detail useful towards understanding the material, though there were parts that did seem to be basically a more fancy way of stating the obvious. The reading caught my attention more when it was focused on systems that I had used/was familiar with; so the outdated-ness of the material was a detractor.
Ling Chen - Feb 23, 2009 04:45:52 am
It was interesting to know how things have changed from the control architecture to the direct-manipulation interfaces. Personally, I like having control over my programs. Sometimes it might make sense to let the program have more control, but most of the time, I believe, the user should be free to do as they will. That allows the user to have more interaction with the system. It was also interesting to learn about the windowing system. I didn't know before that a complete application can actually be viewed as different fragments organized in a tree structure. The user can control the placement of the root windows through a software called the window manager. The interactions the user has with the input devices carets all types of events that need to be interpreted by the system. Now I know that there is so much going on behind all these event handling. It is not easy to create an interactive application where the user is in control.
Adit Dalvi - Feb 23, 2009 04:50:43 am
I thought the reading was way too long and detailed to explain the “basics” of event handling, considering a lot of us have already done a lot of event handling in javascript. This reading did help me re-enforce my concepts about the main event loop and system calls to the various event handlers. The other parts of the reading pertaining to handling the events was really boring because I’ve already done a lot of this in creating form based applications and in CS184, where we have the OpenGL main loop and the event handlers it calls. Overall, I think this reading basically gave me a very detailed version of basics that I already knew (and had learned through much easier tutorials and explanantions).
Anatol Tsang - Feb 23, 2009 05:28:51 am
Whoops! We have reading.
After reading this, I realize that the normal user interfaces we encounter in our operating system are a lot more complicated than I thought. I didn't realize that different operating systems had different ways to "classify" windows and events and whatnot, and that discussing elements between the different operating systems is a little difficult (the right terminology has to be used). I also didn't realize about the main loop: I guess something has to keep refreshing and checking for events in order for this interface to work. Other than these basic things that I didn't realize about user interfaces, I thought most of the material was self-explanatory and obvious.
Chao Michael Zhang - Feb 23, 2009 05:37:43 am
My first impression of the reading was that it is very archaic. Many of the examples, terms, and concepts might have been state of the art back then, when those things were being developed, but now they seem like everyday things and ideas that we all grew up understanding. For example, there is a section in the reading that details mouse button events as being “among the most important…”. It goes on to also talk about double-clicking…
It’s also possible that I feel more familiar to these concepts than others who read this article, since I’ve had some experience in dealing with Events in the process of coding Javascript for websites. Javascript has Event handlers that handle many of the events described in this reading.
There were, however, some interesting concepts that I learned about for the first time. For example, the fact that windows are handled as trees and that events are directed to a single window is something I’ve never thought about or heard of. It’s interesting that it’s handled in that way.
David Jiang - Feb 23, 2009 06:56:59 am
Overall this chapter was pretty interesting. It talked about the different systems that take advantage of "windows" and then it goes on to talk about window events. I have to admit, this article was too long, and it got way too detailed to the point where I lost interest. It could have been condensed a great deal and I probably would have gotten more from it. The part where it break up the windows interface was really interesting though. I didn't know that the system can be broken up into different parts to be managed over a network. And it also reminded me that "windows" isn't an application, but just a GUI to interact with the system itself.
Shendy Kurnia - Feb 23, 2009 07:42:03 am
OK, I thought, without paying attention to its title, the reading will talk about MVC and Event handling. Anyway, it is an informative reading about event handling. I wonder though whether event handler has to keep up with hardware. Usually, if I program in Javascript let's say, the event handler is already provided by the web browser. Let's say a touch screen can have multiple inputs for a "mouse positions". Should web browser provide new event handler to deal with it?
Eric Hernandez - Feb 23, 2009 08:08:04 am
It is interesting to know that pointing devices such as a mouse used to be sampled and eat up system resources before operating systems switched to the event-driven paradigm. It was likely easier to implement at the time. It's nice to know that all of the terms I have become familiar with in Java stem from more general terms as mentioned in this paper. Modifiers/flags for the shift key, redrawing, mouse/keyboard events etc. are all things to worry about in Java programs I have written and the naming of the methods and fields are consistent with old terminology. This is a great realization since it means I probably don't have much more to learn in terms of how interfaces work in Flash! I enjoyed how the article went into a little bit of detail as far as how systems keep queues of events to be processed, as well as other system independent details like WindowProc event handling. I actually never knew that the X windowing system was originally designed to be server-client interface interaction. The only downside to this article is that, indeed, a lot of it was a sort of review for me such as mouse focus, psuedoevents and parent notification.
Salman Rahman - Feb 23, 2009 08:37:20 am
Though this reading makes references to things that are outdated, it was interesting to see the applicability of old knowledge to our current time. Event handling is a crucial part of UI design, which I guess is why this article was so long. I had to break this up over the course of the day to prevent myself from falling asleep. A lot of the things it talked about were things I have seen before w/ VB and JavaScript. JS offers event handling for when the page loads, when the user clicks, etc. as is similarly described by this article. I think I understood the section on the main event loop. The main program initializes information, but is otherwise minimal. It runs a loop which gets events and then delegates handling of those events to the proper programs.
Meiying Li - Feb 23, 2009 07:38:01 am
The idea of a event table and the WindowsProc, as introduced in the article, is similar to the interrupt table model built in the lower system level that I learned in the OS class. But the Object Oriented Event Handling Model is my most favorite. It is much easier to understand and manage.
Also, the fact that double clicking is not available on applications that require communication between the server and the client is because of the time delay double clicking involves is interesting. I remember when I first get online I was confused about opening a link with just a single click, since I was too used to the double clicking way of opening things in Windows. Now I know why they have to come up with this new way for web pages.
Sum Sum Wong - Feb 23, 2009 09:09:15 am
We can tell from the Mac interface shown that the reading is pretty old already. It described the event handling of Operating systems back then and so that we can compare those with the OS UIs right now. I found this reading actually quite interesting because this is the firzt reading in this class that mentioned the implementation of UI which is quite enjoyable for me (and I haven't been exposed to UI implementation too much). I like the part that introduce the methods in event-handling class as it told me that there is more mouse operation than click and mouseOver. I also like the tree representation in the reading that shows things unexpectedly clear.
Matthew Can - Feb 23, 2009 10:04:44 am
The reading explained the importance of having standard code for window management. This is something most of us take for granted, but just try to imagine what it would be like if each application on your desktop had its own controls to move it around, re-size it, minimize it, and close it. We would all have to memorize hundreds of commands. And this is not just a benefit from a usability standpoint. Apple, for example, competes heavily on the unique and visually pleasing style of its devices. The way Apple ensures that application developers build interfaces in the vein of the Apple style is through standard windows.
Anjana Dasu - Feb 23, 2009 10:16:27 am
This reading seemed more technical, for lack of a better word, than what we've had in the past. I thought it was very informative and clean-cut. It gave an overview of windowing systems and event dispatching/handling and went pretty in depth on things like mouse and keyboard input. I don't really know what I should write in this comment because the reading was very factual, and it's hard to take any opinions on its content. One interesting thing though was that reading this article made me play around with my windows and their controls and take note of when things are being redrawn, etc.
Kevin Nakahara - Feb 23, 2009 10:22:06 am
I was surprised at how detailed and comprehensive the article was for a basic introduction into window based UI. I suppose I'm not really all that surprised by anything in the reading, since a lot of it seemed pretty straightforward to me. Obviously an event loop is going to have to run in order to take inputs, you have to listen for mouse clicks, etc etc. Also, I felt that the discussion of the windowed UI seemed a bit tedious, but perhaps that's because we've taken it for granted. I suppose that the reading is rather old, and that windowing was relatively new when the reading was published, explaining the careful detail the author uses to describe terms such as scrollbar and window manager.
Andrew Chen - Feb 23, 2009 10:07:57 am
This article gave me new insight into why most UIs are based on the windowing system: because when many applications are running at once, giving each one a separate window in which to run and to communicate back to the user makes things manageable and organized, and prevents chaos. However, that gives me a question: the windowing system (complete with draggable, resizeable windows with more or less the same ways of manipulating them) seems like just one idea out of potentially many. Is there possibly an even better, completely different UI paradigm with which to manage the chaos of running applications?
Michael Cohen - Feb 23, 2009 10:28:56 am
Although I am interested in the general event driven UI subject, I found the article pretty dry, and honestly kind of hard to get through. Unlike some of the other commenters, I didnt mind the age of the article, as none of the basic ideas have changed, I minded the pace and style, which I found very off-putting. However, looking past that, Event Driven UI is clearly very important to UI and the HCI field in general, because most interaction people have with computers, except for the completely passive, deal with handling events.
Gregory Leshner - Feb 23, 2009 10:31:52 am
While the paper was a bit long, I enjoyed reading it. It was like taking a walk down memory lane of outdated operating systems. That said, it provided really good background on the basic events that are needed to build a direct manipulation user interface. There is a lot more complexity involved than I would like to have to deal with when I simply want some user input. Thankfully, abstractions to handle most of these functions have been put in place.
Alexander Cho - Feb 23, 2009 10:38:34 am
It was very interesting to read such a detailed paper on something that is so second nature to us. As I volunteer to teach seniors how to use computers I've run across some that have never used a computer before. It was very odd for me to see someone not know to to double click, drag and drop, resize windows, etc. I could really see Windows UI experience from the very beginning. After using unix for the first time in berkeley (in cs61a) I remember being utterly frustrated and really start appreciating windows, but later on as I got to unix I began to appreciate the simplicity and speed of unix. Funny how that trade off worked. Also after programming some java swing applications and reading this article you start to truly appreciate the many applications that we use and the many features that we overlook that we feel should be a given for all programs.
Szu-Chun Mao - Feb 23, 2009 10:51:55 am
This article is somewhat old; however I feel that it still provides relevant information on event handling. I gain a good understanding of how the windows event driven UI works and how it is related to direct manipulation to the users. It also shows how the software is structured in Macintosh. It is nice that the author explain the basic concept of event handling using both the Macintosh and Windows. I will definitely give more thoughts to my flash/flex project after understanding all these different types of events and how they’re handled.
Siddharth Shah - Feb 23, 2009 10:49:22 am
I thought this article, although slightly on the long side, was interesting at its core. It was more technically-oriented or technically-based than most of our previous readings, and he went into great detail about the different kinds of windows and the event broadcasting that goes on behind the scenes. I think it's actually kind of funny that this sort of stuff is so crucial to apps, yet most of us don't even give it a second (or even a first) thought. On the other hand, I do think that this reading could have been condensed quite a bit, and it is slightly dated, but what in the world of computers isn't?
Aaron Hong - Feb 23, 2009 10:43:27 am
It is funny how I've never noticed a very obvious fact about a Even Driven UI. In an event driven UI, the control is in the users hand while in older interaction models it is in the programs hands. In some sense, we lose power when we subject our UI to the event driven model, but the gain for the user is so much greater that it is worth it, that is why most programs these days are based on such a model.
Also other than giving the user the control to input what they want, when they want (roughly since the program can still restrict them), the server-client model of an event driven UI gives even more control to the user--the control over their location. A user can even be interacting with the server in multiple locations, and trigger different events that converge to the same environment. As long as they have a dumb machine, they have the freedom to choose the physical location with which they essentially interact with the same machine. This reminds me that there seems to be a movement in this direction with the advent of web 2.0 and the possibility with a OS rich environment through the window of the browser. It'll be a step in that direction with the release of the G-drive.
Raymond Young - Feb 23, 2009 10:54:43 am
It was cool to see under the hood a bit for how different operating systems work. The mouse click events will be very useful, but this reading seemed to open up the possibility of having a game with many sub windows, and not just one game window that the os provides. So what I imagined was that we could almost create what looks like a mini os inside of our flash/flex game using windows and things. I guess I wondered how powerful ActionScript was since I don't have much experience using its more powerful features. It was also interesting to see how much I've never noticed certain qualities about different operating systems that surprised me when I read this chapter. The most notable was how X Windows has no double clicking mechanism. I had never considered that when using my instructional accounts that still use the common desktop environment, I don't double click at all, and yet I had never noticed this until I scoffed at how unusable such an interface would be. I guess since unix on our inst machines don't have icons it doesn't matter. Also, it's easy to forget about the no double clicks rule once you open a program like Firefox, since it's not difficult to simulate the double click by comparing time stamps.
Carolchen - Feb 25, 2009 12:07:14 am
I found this reading to be very long, boring, and ineffectual. I've done some event programming, but the reading obfuscated its explanation in a very long-windede way. With this type of subject matter, the authors really should have used more figures to show the relationships between windows and between events, and snippets of pseudocode to demonstrate the coding logic. I appreciated their attempt to show the implications of different event handling implications in different platforms (such as with the 1- and 3-button mice), but ultimately the concepts were lost on me as the reading was too dry, and the concepts to difficult to picture.
Mark Dhillon - Feb 25, 2009 01:14:45 am
Wow, I gotta say I enjoyed this. And lately I haven't been enjoying these readubgs. I think the idea of lo-fi excited me because it seems that it can really affect the development process in a spectacular way. I really liked the point the author made about how the hand-made interface makes users focus on content rather than purely appearance. This makes perfect sense to me because personally I've wasted development time "prettying up" an interface before showing it to my boss. Even though it worked, it wasn't terribly efficient, but it sure looked nice. I also really agree that Hi-Fi prototypes take way too long to make, and by the time they're done nobody wants to start over from scratch (even if the developers do, I'm sure the people above them have a deadline in sight). It's such a simple idea, but Lo-Fi is truly a significant concept. Good read. Go bears.
