Model View Controller and Event Driven UI in Android

From Cs160-sp08

Jump to: navigation, search

Lecture on Feb 19, 2008

Slides

Lecture Video: Windows Media Stream Downloadable .zip

Contents

Readings

Benjamin Lau - Feb 16, 2008 02:55:30 pm

This reading felt different from the others in that it seemed like a guide to the history of event driven UI and not so much a piece of inspirational material (like the previous readings IMO). One interesting comment in the readings though is that in the DOS + UNIX architectures, the user is in control-- users did what the program asked them to do and only when the program wanted them to do it. If a program needed user input, it would ask for it at the prompt. User interfaces were a lot simpler this way. Another interesting section is the one on XWindows which dealt with the situation in which the user and application were on separate machines. This presents a host of new problems, such as registering double clicks as double clicks (rather than 2 single clicks due to network latency). Another interesting thing was that there were so many different models for object communication, eg objection connections, parent notification, and via simple callbacks. I think I prefer parent notification, because an object might have more than one object that needs to communicate with it, and if the object interface later changes, this would invalidate a lot of code. Having all inter-object communication occur at the parent would localize all changes to one section I think.

Gerard Sunga - Feb 17, 2008 10:06:09 am

As Benjamin stated, this reading was quite different from all of our previous readings, since it seems to offer a brief technical overview over the internal workings over most of the popular user interface/windowing systems. One of the more interesting sections of the reading for me was the transition from the relatively bland event handling (usually involving the use massive switch statement or a set of cases) to more of a more object-oriented paradigm. I like the freedom to do nearly anything due to separation of the elements and the resulting simplicity in development. The following section on inter-object communication was also fairly interesting, and it seems like there's no simple method to implement this with all the possible solutions suffering from complications if there are enough objects involved.

Nir Ackner - Feb 17, 2008 11:40:43 am

One thing that it seems like the reading under-emphasized is the importance of smart default actions for widgets. 90% of the time, there are only one or two ways that we would use a given widget, and providing those makes the job of the programmer much easier. For instance, HTML is often used in prototyping because the default actions it provides are almost all that is needed to roll out a quick and effective interface.

I am curious how HTML as used on the web today, fits into the techniques Olsen discusses. It seems like there is heavy mixing of different approaches, with callbacks (as in AJAX) and parent notification models (seen in event bubbling), but no use of the subclassing of UI elements.

Jonathan Chow - Feb 17, 2008 06:37:57 pm

I would have to agree with the others that this reading was much more technical and historical than the other things that we've read. To be absolutely honest, I found most of the information pretty boring. One of the things I did find interesting was how different platforms treated button presses and holding buttons. One such example is the Key Dispatching section. In order to determine where the keyboard input is being directed, you could choose to use the mouse's current location, you could decide to choose the window that was last clicked on, or choose the window that is in front. Although I feel that the second option and last options make the most sense, if you compare these ideas with the Raskin readings, since the mouse is presumably where the user's focus is, it might make sense to have that direct where the keyboard input is dispatched.

Glen Wong - Feb 17, 2008 08:43:23 pm

As others have noted before me, this reading was quite a bit heavier that the previous ones as it was quite technical. The history on window management systems was quite eye-opening and intriguing. Though I personally felt the reading tried to present too many details in too short a span. Forty pages does not provide enough room to give a good idea on how a window management system works, let alone present how various different windowing systems work. That being said, this reading was particularly interesting to me because prior to reading it I was poring over an OpenGL tutorial and was quite confused over the parts that dealt with setting up a window in the window management system. It is interesting to see how the concepts that went into designing window management systems for operating systems have made there way into other areas such as web design. Another person already made this comparison in his post, but I would like to add the observation that the DOM structure seems to be a clear transplant of the idea in windowing systems that all elements in a window are represented in a tree structure.

Maxwell Pretzlav - Feb 17, 2008 09:01:41 pm

I'm not sure what the goal of this reading was, as it is ten years old and refers to aspects of GUI systems that are pretty much irrelevant for Google Android and so well swept under the rug of the other GUI system that I'm familiar with, OS X, that I've never had to worry about 90% of these issues. The main message I got from this (rather lengthy!) reading was that wow, writing GUI applications sure has gotten a lot better in the last ten years!. If that was the desired result, alright! If the goal was for us to understand the general concept of events, event queues, and message passing in the use of user interfaces, I think less than half the reading would have sufficed, but maybe I'm biased because I've already encountered most of that in OS X (which is just a superset of the NeXTSTEP discussed in the paper).

Khoa Phung - Feb 17, 2008 10:22:03 pm

This chapter was a nice review on the problems of Event Handling over networks in the past. However, considering that this book was published in 1998, the problems have disappeared due to improvements of networking and processing power. Even handheld devices over wifi or 3G networks are much faster now then the problems mentioned in the chapter. It feels like it is the same with the processing speed. Programmers used to spend a lot of time to make programs efficient and fast. Over time programmers were not much concerned anymore as processing speeds increased and therefore made their programs faster. I can see the same for the networking issues and event handling problems from the past. Technology pretty much took care of it and continues to improve rapidly; especially now in our time of the internet revolution. However, it is always good to know what the basic thought process was behind all the technologies.

JessicaFitzgerald - Feb 18, 2008 12:19:45 pm

I liked the fact that this reading went into more technical details than any of our previous readings. Unfortunately the applications the author referred to as examples, have changed a great deal since the article was written, which confused me quite a bit because I had no idea about how the interfaces for these applications were when this article was written. I did find it interesting that understanding "main" in a user interface program doesn't do anything for your understanding of the program itself, instead you must understand the code that handles the windows. I also think that it is a good thing that you are able to do the same thing in two different ways, in microsoft word for example, such as moving a selection of text. I think it makes it much easier for the user depending on what particular task they want to execute and what will be easier for them.

Bo Niu - Feb 18, 2008 01:19:37 pm

In Basics of Event Handling. Developing User Interfaces. Chap 4. Olsen has pointed out that the main difficulty of making user interface today is due to the fact that the user is in control instead of the machine now. The users decide where they want to go and which application they want to send this input to. So the user interface have to meet all these needs. Olsen discussed how event handling is used to solve this problem by treating everything as an event and use a event loop to keep track of what's happening. He then discussed how the event handling can be implemented.

Eric Cheung - Feb 18, 2008 02:12:21 pm

I have to agree with the previous comments about what exactly we were supposed to get from this reading. As opposed to our previous readings, this one was much less conceptual. In fact, the amount of examples was kind of daunting given that we haven't actually started coding anything yet. I'd imagine we probably don't have a whole lot of flexibility within Android as to how to implement event handling, but I guess this reading gave me an idea of what approaches are out there. I suppose once we actually start coding our projects, we might find some bits useful, but for now, I honestly don't think I'd remember most of the code snippets, models, or diagrams presented in the chapter. I appreciate the need for more object-oriented event handling, but the chapter kind of stops right there.

Randy Pang - Feb 18, 2008 02:19:12 pm

This article was a bit too much history for me. While I did find it a bit interesting to see how event handling evolved in it's early stages, many of these things really just seemed second nature if you ever coded with HTML and AJAX, so I would have much rather read about the way event handling is currently handled (so like modern OO and the DOM. I also think that MVC represents a really good message passing ideology. I would have also liked to learn more about SOAP and why it sucks so much [also why it gained so much traction to begin with]. New emerging ones that I'm not aware of would be really cool as well.). In addition, though the article was quite lengthy, I felt that it often spread itself too thin in describing each ideology (the code snippets didn't really give me a really good idea of what was going on because they were all in the abstract, it would have been nice to have a real world example interface and walk through an ideology using that). While I do believe that this article was important at the time (NeXTSTEP was really revolutionary), I feel that as the next generation of UI pioneers, we should be reading about about UI's and ideologies that are stirring up revolutions at this very moment.

Alex Choy - Feb 18, 2008 02:49:14 pm

I agree that this reading is heavier than usual. In the first half of the chapter, Olsen makes comparisons and gives examples using the XWindows system. Of the many things that he pointed out, he said that one big limitation is that many things are harder over a network such as double-click timing. I noticed that current versions of the Xpaint application act more like NeWS and the language FORTH because they send a batch/block of data to the X Server instead of sending repeated updates. This chapter offered many different implementations of interfaces. I believe that the Parent Notification Model made the most sense for a windowing system because it gives more structure and hierarchy to an application.

Ilya Landa - Feb 18, 2008 05:11:38 pm

Unlike previous readings that tried to describe the theory of UI, this reading felt like some project description – divided into bullet each describing how something should be implemented. The technical details are useful as long as they are in some way relevant to Android applications. I did like the fact that the paper described how the applications should handle themselves when user is in control – people in MAC should pay more attention to it because the more “creative” a MAC user gets, the higher the rate at which the function “Force Quit” needs to be used on an application, or on the entire machine. Also, I clearly remember a certain Professor promising us a shorter reading for this weekend (or was it the last weekend?).

Chris Myers - Feb 18, 2008 07:16:19 pm

I thought this was a fairly good, albeit old introduction to event handling. It was interesting to note the different approaches each system took when dealing with the interactive user model. Since the user has taken control of the machine. The software has to draw the screen, and stay in an infinite loop and listen for events from the user. When an event occurs, the appropriate function is called to handle it. The model is similar across platforms with a few exceptions. Notably X with it's native client/server architecture.

Andry Jong - Feb 18, 2008 08:33:55 pm

In the article by Olsten, "Basics of Event Handling", he described how different tasks are done by different operating system. Some, of course, would work better on doing one thing rather than the others. However, an interesting fact is that most graphical user interfaces are "organized in trees of windows" and that the main program for these user interfaces only consist "of initialization followed by loop that gets events and dispatches them to the appropriate objects." Although, knowing these facts of user interface are truly intriguing, I find the technical side of the reading to be not very thorough.

Benjamin Sussman - Feb 18, 2008 09:04:03 pm

This incredibly dry article was a slow arduous read which left me wishing I could be coding instead of reading. While I will never argue against the pedagogical value of history or in-depth explanations of how things work (if you understand how the CPU cache works it helps you overall write more efficient programs knowing that it's not only the algorithm which needs to be fast...but this is an aside.) however this soulless article on the event driven nature of interactive display systems and the points and commonalities of windowing systems teaches newbies little of serious worth and teaches only obscure histories to the more veteran programmers. The event driven nature of UI programming is certainly tricky and quirky and it takes a bit of getting used to (especially Java's extremely wordy Swing which requires numerous classes to act as the objects viewable on screen, or listeners, or as the events themselves and it gets way out of hand very quickly) but I didn't find any help in this article. No sound advice, nor soft landing into the prickly world of threaded programs and numerous interrelated classes. Certain useful tidbits, like the nature of how the computer learns which object your "click" corresponds to, for example, are interesting to know, but could be figured out for one's self given some experience using a windowing system (I am assuming all of us have used either Windows, Mac OS anything or any Unix or Linux distro after 1995) and some knowledge of object oriented programming. It was only later in the article did I find myself a bit more interested, but that might have been because the writing was just vague and peculiar enough for me to be confused by the code they were showing, and it's fun to be confused sometimes. I can't wait to start some serious coding in Android though!

Cole Lodge - Feb 18, 2008 11:07:51 pm

Out of all the readings we have done, I would have to say I enjoyed this one the most, this is probably due to the fact that it is a much lower look at user interfaces than the rest of the readings. It was nice to see how far user interfaces have come, and I guess I should be thankful that I will be doing my programming in android instead of XWindows. One thing I do find interesting: even though the number of events that need to be handle in a modern aplication have greatly increased over the years, the amount of work to handle all of the events has seemed to decrease. As the languages progress, allowing for more events, the job of handling these events seems to be getting easier.

Gary Miguel - Feb 18, 2008 11:02:29 pm

This reading seems to indicate a rather drastic change in focus for the class from high level design principles to low level implementation details for specific UI's. As someone who has used UI's all his life, it is very interesting to read about how they are actually programmed. It's hard to keep track of what's important when the reading consisted largely of comparisons between different windowing systems and their historical relationships, but hopefully in lecture the important parts will be made clear. The general concept of event handling was new, and I guess that was the main point of the reading.

One thing I appreciated was the clarification of the X terminology: I never understood before exactly what an X server or client was.

Yunfei Zong - Feb 19, 2008 01:56:10 am

This reading provided a much more down to earth example of user interface design at the implementation stage, and was a relief after all the wishy-washy design related talk of the previous readings. It's organized as a list of things programmers should know how to implement, so there isn't really anything worth commenting about. However, I do find that the systems that the author was talking about to be way too outdated, and the code samples he gave to be quite useless. It would have been much nicer to include a reading about how to implement the same things in Android or give some background on Android instead, since we do have an Android based assignment due soon.

Gordon Mei - Feb 19, 2008 02:59:47 am

Olsen covers a variety of topics in event handling, including that of double clicking. The articles points out that the original Mac existed under the constraints of only one mouse button and a Shift and Command keys for possible mouse actions. This suggests that the double-click developed out of necessity from the confines of this restriction, where a single click would still provide some intermediate step like selection, and the rapidly following click would serve to open that file. With the growing number of web applications and, beyond that, mobile applications (single tap by button or touch), you have probably noticed that the double-click has largely disappeared, or at the very least diminished in that medium. Going back to that article, Olsen added that because X was run over a network on machines that were relatively slow, to the extent that double-click was a problem. Whether this played any role in the prior observation, I'm not entirely sure. But I have observed family members in their 40's and 50's exhibiting trouble shaking off the double-click habit when involved with actions on the web like link clicks, and it's interesting to see how this long-established convention has quietly taken a lesser role in the functions of daily computing.

Edward Chen - Feb 19, 2008 03:07:35 am

This reading was significantly different from the other readings as it showed actual implementation of the models they were talking about. Nevertheless, the reading was still interesting. It was rather intriguing to read about the history of GUI development and how new GUIs built on top of pre-existing GUIs to fix the inherent problems of the new problems. This is especially obvious when one compares modern-day GUI development to the ones that the reading talked about since GUI development has changed so much, constantly evolving and improving upon the previous models to the point where many of the problems that the article mentioned are no longer apparent or have to be dealt with.

Katy Tsai - Feb 19, 2008 02:46:48 am

After going through the step-by-step process of our interface design in the Contextual Inquiry assignment, I couldn't help but evaluate how the issues discussed within this reading translated to the mobile phone. An interesting point was how we control input and expand the idea of input on an interface by utilizing different commands and input devices. While the computer is guided by the mouse, and a plethora of keys and keyboard combinations, the mobile phone is limited to option menus (which itself adds an additional window), the number pad, and the limited selection tools and arrow buttons. The cell phone interface requires a very linear approach to the window system because of its reduced size. We are limited to accessing one window at a time, and switching from one window at a time requires us to exit an application to enter another. It's not guided by a vague positioning of the mouse and all the nuances of mouse clicks, rollovers, and double clicks, and while this may present the phone as a simpler tool, it complicates things by taking away the options that we are so accustomed to.

Hannah Hu - Feb 19, 2008 07:54:13 am

I have to admit that my eyes started glazing over a third of the way into the reading. While the low-level perspective of UI could be intriguing (if I paid attention), the fact is that we take the many actions described - double-click, mouse-down, window focusing - for granted, and the reading digs deep into the technical process behind those actions... which I doubt we really need to know. Since the publication of the reading, much improvement has been made with networking and UI implementation, to the point that the article loses relevance today.

Ravi Dharawat - Feb 19, 2008 08:00:45 am

I found the material in this reading interesting because there were quite a few things in it that I hadn't given much thought. The biggest eye-opener was X, since I hadn't really thought about how being networked affected UI programming. I found the material disinteresting at times because some of the things discussed were belabored explanations of what is common knowledge through experience. What I am thinking of when I write this is the explanation of the tree-structure of windows and the algorithms involved in window-focusing. These are apparent and intuitive ideas. Of course, the explanations of how systems I was less familiar with worked were quite interesting.

Zhou Li - Feb 19, 2008 10:07:13 am

In the reading, Olsen explained different aspects of event handling in interface design by giving concrete examples implemented in systems such as Macintosh, X, and NeXTSTEP. All the popular systems including the ones just mentioned are rectangular windowing systems, because adjustable rectangles are natural and easy to organize on computer monitor; they are resemblant to overlapping objects on our desktops. Before the reading, I haven't really thought about how network based systems like the X handle windows differently from single-machine windowing systems. For network based systems, it makes sense to have a separate process on user's terminal to handle windows management instead of letting each software handle its own window, since the actual applications are running on a central client.

Jonathan Wu Liu - Feb 19, 2008 10:27:50 am

I guess this is given to us right before our first programming assignment, just to show how basic UI is programmed. I actually was expecting the reading to cover a model view controller programming perspective, but it instead gave technical examples of how to program events. I think it's interesting how many different peripherals work with the same programmed interface. Did the peripheral set the standard for events? Or did the applications make the peripherals? Since peripherals such as the mouse and keyboard have been around for decades, what new application with new events will erode our current peripherals which will require entirely new peripherals? A step towards this has already been made with gaming keyboards (eg. keyboard for WoW)

William tseng - Feb 19, 2008 10:59:53 am

I found the reading to be particularly useful especially since this is the first reading that gives an in depth technical explanation on how existing UI's are implemented. Of particular interest is the example in the Reading about X Windows. Our application for our group project will probably end up being something where the application is run on the server but the window viewing the application exists on the mobile device. Our group may be interested in adopting this approach towards setting up our application. It was also interesting learning how different systems handle the windowing events mentioned however because we are developing an application for a mobile device I do not think we will be giving our users the flexibility to be resizing a window. While we still have to consider the initializatino and destroying of new windows our application will be less involved on this front than the examples given in the reading.

Hsiu-Fan Wang - Feb 19, 2008 11:31:50 am

I'm going to avoid the ongoing "wow this reading is totally inapplicable" pile on... though I agree, many of the issues that the reading discusses should be solved by a decent UI library (and Android seems at least decent).

The most surprising thing I got out of this reading was the level of convergence across different platforms. Even though the underlying architecture are drastically different (FORTH programs that generate PostScript!), there are analogous events (the different redrawing events are a surprising example as that is something I would not have expected to be so widespread). Like Nir and a few others have mentioned, this sort of convergence can be seen in modern toolkits, from plain HTML/JavaScript to the Java SWT library. It actually makes me wonder if this convergence is the "best" solution to developing an interface or simply a case of "most familiar".

David Jacobs - Feb 19, 2008 11:38:17 am

To Khoa: Though I agree that most of the technological challenges presented in Olsen aren't really significant anymore, that's no reason to stop optimizing our code. The argument that "it will run in real-time n years from now" is just an excuse for bad programming practices. No matter how fast your processor, there will always be a task just too demanding to run on the current hardware without software optimization. Standard interface paradigms like mouse, keyboard, and display are trivial in realtime now. But vision based interfaces and accurate speech recognition demand so much processing power that it seems unlikely Moore's law alone will save us (assuming it's even still in play). Just as fast as new technologies "solve" interface problems, they create more interesting interface challenges previously though impossible.

Lita Cho - Feb 19, 2008 11:44:58 am

Olsen's article seem really technical rather than conceptual in our other readings which was not what I was expecting. I believe it was useful learning about the nitty gritty details of event handling and tying in our design concepts into programming. I learn a lot about designing on the programming aspect by organizing the window by tress with a short description. I never realized that the placement of small things-like scroll bar, shortcut labels and pop-up windows-can be created into a tree. Most of the time, trees are used for bigger conceptual ideas. However, I don't think the reading is practical without some sort of lab or homework assignment to compliment it. They gave examples of handling loops and being an active listener. But without actually programming, the article falls flat. I enjoyed learning more about communicating through objects with widgets. I think this will be very useful for our project as well as knowing how to communicate with other devices. Again, I believe people would retain this information better with excercises rather than a really long guide.

Andrew Wan - Feb 19, 2008 11:59:10 am

I didn't find the reading terribly useful in the context of building a UI, but it did a good job of outlining the history of event driven interfaces. The discussion of Postscript/Forth and the X windowing system took most of my attention, since I'd known and used both, but never actually knew about their internals. Given the age of these systems, it's little wonder that such issues as network latency impacted their design. On today's platforms, the more object-oriented approach seem better. It makes sense that the parent notification model has become the most popular for windowing systems, if only because of the layered nature of most windows. Events can be handled easily by parent layers, making it easy to create interfaces in XML or some other markup language.

Timothy Edgar - Feb 19, 2008 11:41:45 am

The reading was a bit different than prior readings as it has been noted as it talked a lot more about implementation. While I was a bit unfamiliar with some of the examples they used as they had an underlying assumption that you would know all these systems, most of the concepts spoke rather clearly. It's a bit interesting in that it seemed like a lot of the concepts were rather common sense and that have been built over time to be common sense.

Brian Taylor - Feb 19, 2008 12:05:29 pm

It was interesting to learn about the different windowing systems of the past and how they accomplished various necessary tasks. It was also interesting to read about how one of the systems actually did not send any traffic over the network until the mouse button was released. I personally believe that I would find such a system extremely annoying, because I would prefer to see the window scroll in real time as I was dragging the slider, and not wait until after I release the mouse button. Overall, this reading was longer than I thought it would be and its attention to some implementation seems very different from our rather abstract readings in the past. In regards to the discussion of how various systems of the past handled keyboard and mouse button events, I did not actually realize how complicated it could be to deal with the events. I also have not ever though about how each of the various features of a window (slider, buttons, etc.) could each be their own window that needed to talk to each other. I guess the reading was useful.

Adam Singer - Feb 19, 2008 12:24:18 pm

I really enjoyed this reading as a good overview for how a system handles events. Just as a weary student makes that scary leap from functional programming to object-oriented programming, so too must we make the leap from a linear programming paradigm to the Model View Controller event handling system (or something similar). I had the chance to play around with Cocoa in my free time, and while the separation of data and display makes for highly legible code, it definitely took some getting used to. After getting used to it, however, I feel like I can never turn back. In fact, many programming frameworks impose MVC on their developers (e.g. Ruby on Rails), so it's a good thing I was exposed to this early. In general, I found this reading to have the most practical value so far this semester. Good read!

Daniel Gallagher - Feb 19, 2008 12:19:39 pm

I've been using basic event handlers in many forms for UIs for some time now and I actually found this chapter really interesting because it laid out some of the rationale behind it that I never stopped to consider before. The architecture of X also interested me since I'd never spent much time with it before. It was interesting in the section p98-99 about how choice of events (here in the case of mouse events) reflects what hardware the designers guessed people would use, and brought home how difficult it must be to design with an eye towards future extensibility considering the multitude of directions development could go in the future.

Michelle Au - Feb 19, 2008 12:40:52 pm

As someone without prior UI experience, I found this reading particularly interesting. It was good to read through the history of windowing systems such as on Macintosh, Windows and the X Windowing system as an introduction to basic windowing concepts. The X windowing system was particularly interesting to me because I never understood what it was or how it worked. The section on object-oriented event handling was the most intriguing to me because it seemed like the closest process of implementing UIs today. While other methods of event handling such as the Macintosh, Windows and callback model require programmers to explicitly pass messages between objects, object-oriented event handling seems to greatly simplify this process through the use of abstract classes. However, I can also see how the object-oriented event handling model can also carry a lot of overhead because of all the different classes that have to be created for every type of widget used. I am curious to see how this object-oriented model corresponds to the model used today.

Yang Wang - Feb 19, 2008 12:35:27 pm

This review of event handling is really fun and helpful. Some of the description really drag me into the past. There are surprisingly many features, that we now taken as certain, had long development period. As some have mentioned this reading seems a bit out of time. However, I still found it pretty interesting and useful. It gives us a feeling of how things comes to today's stage. Interface design is not a one step process. To make a good interface, the basic process is to make models, let users play with them and then improve. I would think the main purpose of this reading is to let us review the past and design a better future. Basically, we all know history is to the past and old, but we still learn them. At least learning history can prevent us from making repeating mistakes.

Max Preston - Feb 19, 2008 12:50:49 pm

Umm, so I made a nice comment last night and I was pretty sure that it showed up, but this morning it's gone. Great. Anyway, I believe I discussed how this article was kind of interesting since it focuses on the more technical and practical aspects of implementing a UI, rather than the conceptual aspects of how humans learn to use different UIs and so on. However, this article seemed like it was too architecture-specific to be very useful except maybe if you are dealing with really low level stuff. But since Android does a lot of this kind of stuff for us, we don't have to worry about less interesting things like figuring out how to implement a simple button and we can worry about more interesting things instead.

Kai Man Jim - Feb 19, 2008 12:47:26 pm

I like this reading so much, it is because I found this reading is so much technical with a lot of good information. True, that nowadays computers are no longer working with DOS or command line and users has more control to the computer than limit down to only certain command lines. Different users have different behavior on how to use the mouse and gesture, and what kind of mouse they are using (1 button, 2 buttons, 3 buttons mouse) does effect how the program run in order to get what the users want. I have experience working with Windows, Mac, and Linux machines. And I have a good experience working with the X-server when I am using Linux since Gentoo users have to edit the xorg.conf file in order to make the X-server runs. It does matter on what kind of mouse you use, 2/3 buttons and with or without scroll wheel. If one of the thing is wrong, it will either result in not function properly or will kill the x-server in the middle.

Therefore, I really like this reading assignment although it is kind of long.

Zhihui Zhang - Feb 19, 2008 12:32:29 pm

Forgoing the "this reading is old. why are we reading this?" train of though, I'm somewhat curious in regards to the 'bottom-first' approach and the 'top-down' algorithm for event propagation. Particularly, I've worked with Adobe Flex over summer, whose event flow consists of a 'capturing', 'targeting', and 'bubbling' and seems to include both a 'bottom-first' and a 'top-down' approach. anything good/bad with this model?

Going with Adam's comment about the MVC model being integrated into RoR, i think that it's a pretty good idea since programmers are somewhat 'forced' to follow good practices. (although they can still not not obey the model and put lots of controller logic in the view, put controller logic in the model, etc) I do work in ruby on rails and i find the built in mvc pretty convenient.

Jeff Bowman - Feb 19, 2008 01:11:06 pm

Like Daniel mentioned above, it is interesting taking the concept of event-driven UI (as someone who has done extensive UI programming before) and connecting it to the direct manipulation tenets we used before. In fact, I started programming in Visual Basic 3, so the very beginning of my user interface experience has been heavily event driven: I have a hard time imagining creating a usable UI without it. In fact, that's what I got most out of this reading: Direct manipulation seemed like a very abstract topic when we did the first reading, but in connection to all modern windowing systems, direct manipulation seems like the only way to fly.

Harendra Guturu - Feb 19, 2008 01:29:53 pm

I found the description of event based programming that is generally used for GUI programming not really relevant to this class. The general idea of this class is to create good intuitive interfaces, the implementation aspect of this is less relevant since a different implementation can be used and the UI should work exactly how it was designed no matter the underlying code. The only reason to find the description of event based programming interesting is to see the convergence of many different implementations to use the event driven model.

It is however a good idea to know of the general concept of event driven programming. I remember when I first tried to use Swing, I was not aware of the programming method and found using Swing very strange.

Raymond Planthold - Feb 19, 2008 01:15:59 pm

That was a lot of reading about stuff we'll probably never use. The overview of the evolution of MVC was interesting, but the extended discussion of Xtk callbacks (for example) weren't. It is generally worthwhile knowing how things used to be done, but not at that level of detail. The "how the Control key works" bit was also potentially interesting, but isn't something most of us will need.

I do find it interesting, however, that only recently has there been movement away from the "everything is a window" view described in 4.1.1 for X systems. Even then, it's only in a pre-release version of the Qt toolkit, and nothing else that I know of. It does apparently boost performance, as the reading suggests.

Tam La - Feb 19, 2008 02:01:39 pm

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.

Johnny Tran - Feb 19, 2008 01:52:57 pm

I liked the discussion on the various approaches to handling events that take place in a UI. What I would have liked to see are approaches to actually coding up the interface. I have had experience coding up UIs in different development environments such as Visual Basic, Visual C++, and Java Swing. One thing I learned is that creating UIs using code is highly unintuitive and counter-productive; the UI itself is graphical, but why isn't the language that describes it graphical as well? Visual Basic has a graphical UI builder, but unfortunately its event handling model is fairly inflexible.

The cumbersome effort required in making UIs could be one reason why bad UIs are so predominant. While I feel that textual programming languages are here to stay for a long time, I hope to see progress being made on graphical approaches to UI development.

Daniel Markovich - Feb 19, 2008 01:49:18 pm

Although the article contained a pretty thorough overview of the technical aspects of a windowing system, I felt as though some of the sections were repetitive and boring. Most of us have had years worth of experience with windowing systems, and it seemed as though a large portion of the material just reinforced the concepts that we use on a daily basis. Although I may sound overly critical, I did find the article gave good examples of current windowing systems and how they compared to one another concerning different aspects of the design. I would have found the article a bit more helpful if it went deeper into the aspects of designing a windowing system, and how some of the internals worked.

Jeremy Syn - Feb 19, 2008 02:01:03 pm

I found this reading to be interesting because it goes over a detailed history and background of the event handling. It is interesting to see how systems have gone from the machine being in control to users being more in control, which I think is an important feature to have. It's also interesting that the X Windows system was designed to allow the user to be on a seperate machine from the application, which has been in wide use since the use of applications from remote places is favored.

Siyu Song - Feb 19, 2008 02:11:23 pm

This readings was a little tedious at times. Especially when it walked us through the reprocesses involved in a double click. At the same time it did exhaustively and pretty informatively dissect this common task that gets done so many times without thinking about it. While it was tedious it was at the same time easy enough to read and understand. Everything was laid out painstakingly clear and direct. Though it was a bit hard to read now, I could see myself referring back to this reading when implementing our application.

Jiahan Jiang - Feb 19, 2008 02:08:16 pm

The even driven design is not an unfamiliar concept to most people; the article is fairly straight forward and very detailed. I found the event-dispatching discussion quite interesting; I never knew how mouse and keyboard events are actually handled. Object-oriented event dispatching seems to make a lot of sense, since objects are very much event instances; the translation seems direct and sensible.

Scott Crawford - Feb 19, 2008 02:20:11 pm

As a general note, I think that referring to user interfaces as 'computer controlled' versus 'user controlled' to be limiting. The user always has some control over what actions they choose to take (trivially: whether or not to interact with the device at all) but likewise the device also always constrains the user in such a way as to be partially in control (ostensibly this is the enumerated list of tasks that the device can perform, which will not be a complete list of all possible tasks). I would be more comfortable with referring to the continuum of control which the interface delegates to the user. In this way, DOS would give less control to the user and windowed systems give more control to the user. For the purpose of disambiguation, referring to this as a polar difference is functional, but theoretically you could design a user interface (i.e. some kind of direct neural interface) that makes windows seem as infantile as it makes DOS seem.

Bruno Mehech - Feb 19, 2008 02:29:32 pm

For anyone that has ever done any even driven programming this reading was probably very basic knowledge. The only thing that was somewhat interesting was the talk about the history of event driven programming and how it evolved from the first Mac version with only one application running at a time to the object oriented versions. I also don't understand how this will help us design interfaces.

Roseanne Wincek - Feb 19, 2008 11:50:17 am

I agree with the opinions of a lot of my classmates. I thought the reading was rather dry, technical, too long, and dated. I thought that it included a lot of details without putting them into a useful context. I'm not really sure where these windowing systems really fit in with Android, or how I'm supposed to apply these concepts when designing interfaces for Android. It is interesting, though, to actually think about how a GUI handles the basic tasks of key strokes and mouse clicks.

Jeffrey Wang - Feb 19, 2008 02:43:28 pm

The article, "Basics of Event Handling," provided, on a high level, of how a graphical interface works. Although the windowing system is the standard interface nowadays, the article still allowed to be understand this topic more formally. The event modeling system now allows the user to be in control, rather than the program itself. The article covers all the standard events such as mouse events, window events, main event loop, and object-oriented event handling.

However, it also seems like not much has changed this article has been written. I believe there needs to be much more improvements. For example, the article metnions X windows was built to handle many different amount of mouse buttons. This allowed the possibility for future creativity. One thing that I like is Apple's use of gestures. This emphasizes direct manipulation even more and provides more flexibility.

Robert Glickman - Feb 19, 2008 02:58:04 pm

This reading was mildly interesting. It provided a sense of how different architectures handle events triggered from the mouse and how different models can be used to handle such events. This handling of events in software is often used in web applications, as well, using Javascript. Certainly, I have seen these events before, such as onmouseover, onmouseout, onclick, etc. and many applications use this model. However, this article failed to provide any great insight beyond this, except for the insignificant (for me) details of how different architectures handle such events.

Reid Hironaga - Feb 19, 2008 03:01:19 pm

Olsen's article about event driven programming was interesting as an introduction to the evolution of windows and the handling of mouse clicks, etc. It provides a grasp of the structure which is multi-layered and recursive in nature for many important interfaces. While it is not intentionally entertaining, it is an extensive background of many of the systems we depend on so deeply today. I hope this article will help the development and understanding of models in our applications on the Android project. I find it interesting that I never had a thorough introduction to threads or the methods in this article, and definitely never had any extensive projects depending on its implementation.

Michael So - Feb 19, 2008 03:04:03 pm

This was a technical reading. It also seemed pretty basic, which is good because it provides a base to act as a foundation. I thought it was interesting the the Macintosh was the first to do double-click and everyone started doing that too. That was neat. I don't think there is much to comment on except that it was informative and technical.

Mike Ross - Feb 19, 2008 03:06:39 pm

The reading is somewhat interesting, though if you try out a visual GUI creator, you can learn a lot of the basics concepts via trial and error. It seems like in some sections this is just a reference manual for exactly how a particular system handles different events or structures its window manager, and I suppose that's very relevant to a UI class in seeing what's been done and why we do it now. I'm not going to bash it and say it's ridiculously painful and boring, it's not like it took a significant chunk out of my life, and it's a fairly easy read if you a passing knowledge of how events and interfaces are structured.

Diane Ko - Feb 19, 2008 03:06:42 pm

Much of the reading focused on the windowing aspect of user interfacing and how the mouse comes into play with windowing. This reminded me of one of the key user interface tools that I use for Windows that actually was not included in the original UI. The UI tool provides the ability to hover over a window to activate/focus the window, allowing me to type in a window without it being in the foreground. This changes the focus of the user interfacing from that of direct connection (clicking on a window to activate it) to intention based (hovering over a window to activate it).

Some of the other things that were mentioned reminded me of the differences between different OSs and Windows from my usage. For instance, the X in the corner of the window for OSX will close that instance of the program but not the program itself, whereas for Windows, if the window is the last instance of the program, will end the program. Also, for sizing the window, in UNIX you can only resize the entire window in the bottom corners whereas in Windows you can do that from any of the corners. Other features include the difference between double clicking on the title bar of a window, which in Windows will restore/maximize the window whereas in some OSs it will minimize the window.

Megan Marquardt - Feb 19, 2008 03:21:10 pm

This reading was much more applicable than previous ones, because instead of describing a general concept of what user interfaces should provide the user or the general feeling a interface should give off, it lists specific points that a UI programmer needs to consider. These are concrete, and not just what the user interface should be like.

Brian Trong Tran - Feb 19, 2008 02:34:52 pm

I thought it was pretty interesting how the interaction of software has been abstracted into events. One of the things that got me first interested in CS was video games and I have always wanted to learn how to code them. For me, it was an interesting read on how interactive devices could trigger events that would be evaluated by the software that would then act on those events. Thus, no interaction with the software would be the same every single time that the software was run because things could be different based on user input. I was particularly interested in the part that mentioned how video games have events involving several buttons pressed simultaneously. I had never thought of that when wondering how to code games because lower division CS classes have typically been very serial with one input at any given point in time. Each button could trigger an event in the game, but those same events would not necessarily be triggered if multiple buttons were pressed at the same time. I found this very exciting.

Jesse Albini - Feb 19, 2008 03:21:20 pm

I felt the reading was quite dry, but did hammer across the technical complexities of event driven programming. I also felt that the reading was a bit dated and many of the problems it presented were somewhat moot in today's computer environment.

Henry Su - Feb 19, 2008 03:04:37 pm

Firstly, I'd like to note that this Olsen reading is quite different from the previous readings, in that it is much more technical, leaning more towards computer science and away from psychology. Olsen's information about the windowing system that, I presume, is still used in the present day, is very informative. This is especially true because I had no real experience coding anything for a user interface, and haven't really thought of how scroll bars and buttons really work. I found the terminology odd, however: For example, by the term "window", Olsen means basically every "object" presented in an application's user interface, as opposed to just what we usually call a window. The plus side to this definition is that we can think of a collection of windows as a nested structure, where you can be pointing inside one window that exists in another window. The scroll bar, for example, is one such "window", and is nested inside the main window (the actual window). This nesting strategy is good because controlling the scroll bar can affect the parent window as well, affecting what it displays. I also found the review about event-driven (what we called interrupt-driven before) versus polling very interesting, in that for most devices humans control (like mice and keyboards), using polling would not be a good use of CPU time.

Paul Mans - Feb 19, 2008 03:03:13 pm

I think the best part about reading this article was how it forced you to visualize simple user tasks on a computer in an event driven context. Going through the list of different events that the user can trigger from mouse to window events is surely a useful technique when designing our own applications. I also enjoyed reading about "pseudoevents", another type of interaction that I rarely consider in normal interaction with my computer. Although most of the techniques discussed in this article seemed familiar to me because I have worked a little bit with the Java swing package, it was still interesting to see how events actually get translated to visuals through the window system. I also really like the idea of partitioned window space--I doubt it would be applicable for our android app but very cool concept all the same.

Richard Lo - Feb 19, 2008 03:25:49 pm

Very technical piece, not necessarily useful for moving in different directions with UI but at least a good overview of the historical and evolution of what we consider to be basic forms of UI today. With the rate that UI is changing (to think about it, touch screen and handwriting recognition is fairly new) and the different directions that it is going (like the multi-touch iphones and touch screens), its just more interesting than anything to see how quickly interface changes along with the core technologies.

Brandon Lewis - Feb 19, 2008 03:37:48 pm

Interesting reading on a subject with which I am very familiar. I have done graphical programming on Classic Mac OS, OS X, Palm OS, Windows (MFC, and visual basic), and finally, Linux. My favorite environment is PyGTK which is amazingly slick once you get used to it. Most flexible paradigm i've seen so far.



[add comment]
Personal tools