Model-View-Controller, Event-driven UIs
From CS 160 Fall 2010
Readings
Basics of Event Handling. Developing User Interfaces. Chap 4. Olsen.
Optional
Handling UI Events Android Developers Guide.
Your Response
Please insert your responses direction below by editing this page. Its a good idea to compose your reply with a text editor, and include it quickly. That helps avoids conflicts with other users editing at the same time.
To do that, first login by using your user name and password, edit the page and at the end of it put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.
Frank Chew 14:23, 25 September 2010 (PDT)
This article points out that in Macintosh programs, there is no right click. This must be accomplished via a command key, or this is no pop-up menu. For programming according to these windows events, Microsoft distributed the successful Visual Basic, which lets you drag controls onto a window, and double click on them in order to add code to a click event. This is harder to do in Java, which requires tedious copy/pasting from the internet forums in order to add code to a click event.
Chao liu 15:39, 25 September 2010 (PDT)
For this article, it talks about the relationship between the users input and how the software handling those inputs. There are a lot of ways to do it. And some structure such as GIGO, it provides an event table to deal with all the events that happen in the window. It’s clean that one input, one event. But the drawback is also clean: it’s hard to install new events. Just as the article mentions, make a copy of the standard button event table-> write a procedure->place the address of the procedure in the event table->allocate window data information and so on… so there is a high cost for adding new feature to the exist table. There are some other methods that take care of this issue, such as callback. Anyway there are a lot of information today, it give reader a basic idea that how to deal with the different event and how to handle it. The interaction between the users’ input and how the UI make responds to it is a complex questions and it’s increasingly become important because as the applications become powerful, a efficient and easy UI is essential for all of the users.
Sean Tai 16:44, 25 September 2010 (PDT)
It was interesting to read about the invention of mouse events within a listener framework that would allow the operating system to process mouse events without devoting extra resources to poll for them. This is a simple idea, but an invaluable one, allowing for multiple applications to be run simultaneously more efficiently.
Calvin Wang 17:18, 25 September 2010 (PDT)
I have a question regarding Figure 4-3 in the first reading. It seems, from this figure and the discussion that follow it, that both the user and the user interface are on the server side and the actual application is running on the client side. What is going on here? Isn't this the opposite to our conventions where the "client" refers to the part of the program that runs on the user side and the server provides a service remotely? This makes the following paragraphs slightly confusing. Is there a reason why X/NeWS/Java uses "client" and "server" differently?
Daniel Yoo 22:17, 25 September 2010 (PDT)
This article shows how events are handled and progressed along the way, until today. Most of the actions we do in computer is by simply clicking a mouse and graphical user interfaces are generally built on top of a windowing system so people do not really consider how it built inside. Thinking about interfaces may sounds easy, but when the engineers have to consider software to handle multiple events to interact between users is a complex scenario. As the user interface is getting better each day, the applications become more powerful and open up a new challenge to software programmers.
Andy Lin 12:05, 26 September 2010 (PDT)
The interesting thing that I found in this article is that how the mouse handles different events by different buttons. As the article points out, “It is difficult to do 10 different interactive actions on a given object with only one or even three buttons.” The one thing that I think is hard for design is that make the interaction of mouse natural to human behavior. For instance, people can select one file by clicking the left button of the mouse one time, and can open that file by clicking it twice. In my opinion, the right button of the mouse is one of the most brilliant designs of the mouse. It shows the functions that particular can handle and makes the interactive actions more fluent and easy to use.
Courtney Wang 12:07, 26 September 2010 (PDT)
My first experience writing code for GUIs was with Swing in Java. At the time, I had barely any understanding of the whole event-handling process and windows; the Swing API and model code made no sense to me. It all seemed very convoluted and I couldn't figure out why you needed listeners and handlers and all of these things for creating interactive windows. This article was very enlightening and it was nice to be able to draw corollaries with this and our programming assignments. The way we create subclass for Views is exactly the process described in the reading of overriding standard methods of application windows. One thing I wish the article had talked more about failed attempts at windows and event handling. I doubt this is what the standard started out as; I wonder how other structures were formed regarding this problem.
Robert Connick 13:29, 26 September 2010 (PDT)
This reading was quite jarring because, in relation to previous readings, it took a dive down several levels of abstraction to operating systems and window managers; however, some of the material did seem to pertain to user interface design. Obviously there is the fact that the event model only exists because of the need for a GUI. There are also usability concerns: how can a user drag the scrollbar “thumb” up and down? Is it easy? One design issue that I found particularly neat was how doubleclicks work. At first glance it's a single button that can do different things (select and open), depending on context — a big no-no. But because the actions are closely related and the second logically follows the first, it works very intuitively. Finally there was the talk of widgets and resources, which was helpful in understanding how and why our Android framework works the way it does.
By the way, I too was confused by Figure 4-3.
Alex Aberle 14:12, 26 September 2010 (PDT)
My first reaction is: how old is this book? I'd guess about ten years, maybe more. I have to imagine that event handling has advanced since then, although in my experience with event handling it still works in basically the same way, at least from the perspective of the programmer. I imagine the implementation has increased significantly in sophistication.
I also noted a lot of talk about CPU resources for things like sampling mouse position. That makes me think that this is quite old indeed. I don't think that any modern computer, no matter how low-end, would have any trouble at all with the kinds of performance issues the author was worried about. It's kind of a theme in computing, actually. Raw computing power grows hugely, the types of tasks people want to do don't get that much more complicated. The result is that consumer software programmers can and do get lazy about efficient implementation. Of course, there will always be some areas that need to be as fast as possible, like rendering, scientific computation, real-time operating systems and so on.
Don Arboleda 14:35, 26 September 2010 (PDT)
The article reminds me of my attempts to program Windows applications in C++. It starts off with setting up the window itself and then deposits itself into the message loop, which takes messages, translates them, and handles them. The loop itself is rather interesting because improperly implementing it resulted in the program eating up CPU (like any other loop, really). These attempts also introduced me to the concept of callback functions, though I still only have a foggy idea as to what exactly callback functions entail. It's amazing how in-depth this goes, actually about the event processes of each different, er, I don't know what to call them. When I reached the Windows section, I cringed at seeing lParams and wParams again--I never could understand the odd prefixes that seem to have been added into the syntax.
Steven Kisely 15:29, 26 September 2010 (PDT)
They bring up a great point I never realized how many possible actions there are just looking at a simple pair of windows. It is amazing the number of things that must be tracked with even a simple mouse click. Where was the click down, where was the click up. If it was in the close box but now isn't then do not close the box, if it was a folder move it, were there any modifiers, etc. There are so many possible events it is unsurprising it took so long to move to a GUI environment.
Chris Song 15:58, 26 September 2010 (PDT)
Olsen Chapter 4 really revealed a lot of complexities we take for granted. Even as a programmer, I honestly never thought of the process behind event-handling procedures. It was especially enlightening to see the comparisons between different systems. The amount of information that is hidden from the application programmers makes me feel like an end user rather than a developer! Of all the topics discussed, communications between objects had confused me the most. It almost seems obvious that parent-notification model and connections model are so much more superior to the simple callback model that I wonder why simple callback was thought of at all. Besides, I had difficulty following the ironically named simple callback model. It goes to show that no matter how “simple” the implementation is, if it's not intuitive, it's still very difficult to understand the idea.
Geobio Boo 20:10, 26 September 2010 (PDT)
Mind boggling. When I first started programming in Android, I wondered why it was so complicated. Even somehting as simple as clicking a button is complicated. But the reading explains it very clearly. With such an interface and so many layers of functionality, its necessary to have listeners, to have different windows, zones, rectangles, etc--each with its own autonomy. Not only that, but the various clicks which I usually take for granted requres different programming. A click, vs a click and hold, vs a double click would all have different responses, etc. Cupcakes.
Jonathan Look 20:40, 26 September 2010 (PDT)
I thought FORTH provided a unique way to decreasing network traffic for high-resolution printing by sending a program that could generate the image. However, using a solution like this to address the issue of scrolling on the X server does not seem always user friendly. It may decrease network load, but if a user is holding down the scroll bar with the mouse button depressed, wouldn't the screen information not update until that mouse button is released?
In regards to the Object Connections Model, I feel that this is similar to the Observer Design Pattern. I employed this model before and an object could keep track of multiple observers, whom it would notify on a change event.
Sui Kun Guan 22:45, 26 September 2010 (PDT)
In this article, the author discusses the difficulties of the input devices for windows systems. I interested at most is the complexities of the keyboard events. Before reading this article, I feel that a keyboard is the easiest input device to make. However, it is actually absolutely difficult to build a keyboard because the keys are supposed to work together, on the other hand, a computer will generate an event for a key pressed or released, and the computer usually reads only one key at a time. Therefore, it is difficult for a computer to recognize the two events at the same time to generate a new event. The solution to this problem which is discussed in this article points out that the computer has to filter out all the functional key in order to recognize the two key event, and I feel the filtering event is very difficult also.
Melissa Lim 22:55, 26 September 2010 (PDT)
When thinking about User Experience, I never gave much thought to the problems an interaction designer has to consider. How are events handled within a particular system? How complicated are users' tasks and what sort of support is required to perform these tasks? I particularly enjoyed reading about early event-handling and the evolution from line-by-line text input to interactive software architecture. It was also interesting to see how event handling develops as designers learn more about client-server interaction. Macintosh's introduction of double-clicking showed that simpler design (having only one mouse button) does not necessarily correlate with a cost in functionality (users can still perform the same tasks albeit the manner of doing them are different). Instead of viewing hardware as a limitation, successful designers should see it as an opportunity to innovate and improve the way humans interact with technology.
Raymond Williams 23:13, 26 September 2010 (PDT)
I remember way back when I used win32 API. So messy! And you had to handle everything manually, even a simple window resize. I can still remember how happy I was to get a blank window on the screen. Skip ahead to now, with C# with .Net and other high level languages it's so easy. I just click something and select the event for which I'd like to write a handler. The simple things like moving windows are even handled for me.
While it's nice to have tools that do everything for you, we must remember the higher levels are still just nice frameworks for lower levels. 1's and 0's will never go away, and it helps a lot to know what's going on behind the scenes. Otherwise, you'd just be an artist. A true programmer can use the tools, but also knows why they work.
Karl He 23:20, 26 September 2010 (PDT)
The sheer number of different approaches and considerations for event-driven UIs was mind-boggling. In retrospect, it's not that surprising, however. Just the fact that the user is in control of the interactions makes the system inherently hard to code. The system must accomodate for what the user thinks he is doing. There are still cases in which this isn't solved. Often I have tried doing something like, say, dragging a link inside my browser outside of it to create a new browser window with the page loaded, but was disappointed when it simply dropped a shortcut onto my desktop.
It is issues like this which, in my opinion, define the study of user interfaces and HCI. Whatever the programmer thinks is correct doesn't matter if the user does not think the same way.
Christine Lu 23:40, 26 September 2010 (PDT)
The Olsen chapter really highlighted the difficulties of programming because of the variety of inputs possible. For instance, the chapter gives examples of using alt, ctrl, shift, etc. with any other combination of keyboard strokes, and in terms of the mouse, with double clicks, hovers, scrolls, right clicks, etc. I thought this was interesting if applied to the Archos device because there is limited input available to the user, with only four navigation buttons, a virtual keyboard, and touch input. However, this article reminded me of a previous article that mentioned variations on touch, such as pressure and the angle the finger is positioned at, in addition to a variety of multi-finger options. While this would make programming more difficult, it would also open up many more possibilities, in a similar fashion to the growth of the PC.
Theron Ji 23:41, 26 September 2010 (PDT)
One thing I found interesting was a description of how the X windows system worked, which is what we use a lot in Berkeley CS classes to access the workstations. It explains why it's so slow (all the round-trip times whenever you do anything), and brings up interesting points on why we don't use other windowing systems such as Next, which it describes as being faster. Another interesting fact brought up was how Windows supports double clicks on all 3 mouse buttons (which is typically associated with only the LMB).
Yue Chang Hu 23:44, 26 September 2010 (PDT)
This week's reading is quite interesting because it gives an overview of mouse and keyboard inputs, and how those inputs evolves and interact with the user and the display screen. Given this variety of things being discussed, I am especially interested in the topic of mouse and the various types of mouse used for different operating systems. For an example the mac used to uses a one button mouse, window uses 3 button and X uses one button mouse. They all evolve along with time by having more short cut keys. Like apple would have changed to a double click idea for the mouse and other operating system would have functions that require keyboard and mouse inputs. It is also very fascinating to learn about how mouse interacts between the user and operating system and how designs affect the usability of the mouse. For an example the X's one button mouse would be very slow because it require a lot of network traffics sending current positions of the mouse back and forth.
Jeremy Sasson 00:31, 27 September 2010 (PDT)
One thing I found interesting was the brief introduction into keyboard handling, specifically the case of Apple + Key not being passed directly to application windows but forwarded to the menu system in the place of selecting a menu item. It also seems like this is how ctrl-alt-delete works on Windows PCs when everything else is frozen. One would guess that there is some sort of priority queue implementation, and if this key combination is ever entered, it would be the next event off the queue.
Benjamin Carpenter 01:02, 27 September 2010 (PDT)
I think that while making these windowing systems very flexible is a good thing in most cases, it can also end up turning into a nightmare. While, I enjoy logging into systems remotely and running graphical programs on them which get sent over SSH to my X server, I cannot count the countless hours I have spent messing around with the multitude of options for configuring and customizing X for my local and remote machines. Being very flexible in this way also limits the window system's ability to support what we would consider 'basic' features nowadays, such as the "double-click," which X couldn't support due to its architecture.
Derrick Tao 03:42, 27 September 2010 (PDT)
The mouse event ui has been adopted well by society. Most people understand the concept of left and right clicking. However, mac initially did not have a right click and required a keyboard key to be pressed down. Each operating system has a different way of handling mouse clicks. I however believe that giving more than one button allows for much more interactions with the computer. The article also talked about how the window system works with the mouse inputs.
Tsung Han Tsai 03:49, 27 September 2010 (PDT)
I think it was interesting how the UI was first invented and how events were handled. For example, double-clicking. That's a pretty smart idea to come up with when all you have is one button. I think if given new challenges with no solutions, then people can come up with unconventional ways to solve it, even though if we look back now, we would say it was the only logical thing to do.
Alexander Wong 08:54, 27 September 2010 (PDT)
The way double-clicks were handled seems like a bit of a hack. I understand the challenges involved in implementing a truly separate double-click event, but the way double-click is implemented means that single-clicks and double-clicks are not truly separately occurring events. The solution of selecting and then opening on an additional click essentially boils down to calling a single-click event and then calling the double-click event which is some how more intrusive or prominent to cover up the fact that the single-click event was fired. The single-click event can never be bound to any sort of significant operation then.
Richard Laroue 10:16, 27 September 2010 (PDT)
Any sort of user application without an easy-to-use/understand user interface is worthless, even if the application is capable of doing a lot of useful work. Reading about GUIs and the planning that goes into developing good ones was very interesting, particularly because it pertains to the work we're doing with Android apps in this class. Being able to respond to user's input in a way that is intuitive to them is not as simple as it seems. I did some work this summer with GUIs for an application that I wrote, and coming up with a good interface was not easy.
Avery Gee 10:50, 27 September 2010 (PDT)
I think that the tree structure is a very good way to organize folders. There has been a lot of research that proves that this is a very effective way of storing information in the human mind. People that remember things in tree structure can remember more and remember them for longer. This is because there are categorization properties associated with each node. I think it is very practical that the computer UI mimics this because it makes it very intuitive for the user to navigate the file structure.
It was interesting to read about how different systems work and how some are incompatible with things like double clicks, etc. It seems like it is better to find out how the user would like to do things and then do the coding, even if it is hard or difficult. However, there should be a compromise if the coding makes the system slow to a crawl or something. Then you'd have to find the next best solution for the user.
Samantha Paras 10:49, 27 September 2010 (PDT)
What impresses me is the complexity of the windowing system. We have dealt with event handling a little bit with the applications we have made so far -- such as clicking buttons or creating a drawing on the screen by touching it. But it hasn't been as complex as the Macintosh example they gave which has a lot more items and possibilities. I can see how complicated it can get with many windows open with many applications. And as we have learned throughout the semester, users can be very unpredictable, which can make direct manipulation very difficult.
Vincent Rodriguez 11:21, 27 September 2010 (PDT)
It was interesting to read about how user interactions with "windows" are handled by the underlying architecture of the OS. Though I had a vague idea of how they would go, I didn't realize the amount of thought was put into it so that the processes involved with dealing with these interactions do not overrun the system. It was also interesting to read about how the different OSs that a particular application would run on changed how an application should capture user interaction.
Kyle Gorlick 11:26, 27 September 2010 (PDT)
It's interesting to think how significant certain ui elements were. For example, the double-click, right-click, and window resizing elements. I wonder how much time went in to designing these features. While it may seem very intuitive now, I am curious to know how it was interpreted by people who had never used computers. The double-click for opening programs seems to work well, as the one click will just select it. On laptops without a mouse, it is not as nice however. Now that I think about it, I usually find a way to open applications through one click rather than a double-click on my laptop.
Terrance Ng 11:30, 27 September 2010 (PDT)
The concept of user interactions with the computer through a mouse has been developed through the years. It may not even be the best way, but I think the system in place for handling button clicks, etc., has been so well adopted that it may as well be the 'best'. The window system also makes the concept of having 'multiple items' come to life, and I never realized just how much thought and work was put into designing and developing the system that we see today in every major graphical OS.
Brian Maissy 11:31, 27 September 2010 (PDT)
One thing that this reading highlighted for me was the lack of uniformity among windowing systems, which is often caused by a lack of uniformity in hardware. This leads to a user interface model which was not necessarily designed as a unit, but evolved based on hardware and software factors, and persists by convention. The fact that a double click universally is understood to open an object may be benefitial, because it gives a high level of intuition to interfaces which conform to users' expectations. However, it might not be the most efficient system in terms of current hardware, software, and user interface needs. Basically the bottom line issue is one that was also brought up in other readings: when should a designer allow himself to be controlled by convention, and when should he attempt to innovate? Based on what I've learned so far, my answer is that if he plans to stay within the existing paradigms of interface design, he must conform to convention, or risk confusing his users. Improvements can only be made in a peacemeal, ad hoc way. New, improved conventions will take time to develop.
Aaron Loessberg-Zahl 11:34, 27 September 2010 (PDT)
This chapter gave me a lot of insight on how to put together window interfaces, much of which I would never have figured out on my own. The object-oriented model of using callbacks to handle cascading interface changes feels very intuitive to me, and I look forward to trying it out in my own programs.
My one criticism of this reading is that it should have been assigned before the drawing app, so as to give us a better idea of how windows and canvases are conventionally handled.
Albert Tseng 11:37, 27 September 2010 (PDT)
This article provides a description of the progression of event-handling techniques and the rationales behind them, which I found to be very informative. I was intrigued by the major problems faced by designers of event-handling methods when facing any particular design approach or novel event-handling protocol. The section on communication between objects and the notion of pseudo-events is one that I found especially interesting, as it demonstrates to me that the general nature of events need not be restricted to only user-generated events. Input can be made by originators of any kind.
Simran Chaudhry 11:45, 27 September 2010 (PDT)
Two things stood out from this article: 1. It's "almost universal in GUIs to decompose interactive objects into a tree, based on the screen geometry of the interactive objects." -- Never really thought about it, but that's how our Android XML layouts are organized. 2. A reminder of the different ways you can interact through a mouse (click, left/right, double click, cursor movement) and keyboard (letters, shift/control combinations that do different things, like playing chords on a piano).
Bichen Wang 11:51, 27 September 2010 (PDT)
This was an incredibly extensive overview of GUIs and how event-driven user interfaces work. Although the examples are from outdated operating systems, everything still applies. There are still these widgets and windows with resize and close buttons. Finder and Windows Explorer employ this hierarchical view, even being able to use this idea of a tree as one of the navigation options. Everything that existed a decade ago holds true for stuff now. Even small things like not consuming all the processor for one application is a huge thing now. If a paint program ate all my CPU, multitasking with a processor that can handle dozens of programs suddenly becomes impossible. The idea of event-driven UI scales incredibly well into our current GUIs.
Karthik Jagadeesh 11:55, 27 September 2010 (PDT)
The way the window event handling works is very similar to the coding for the android application. On the Android we wait for touch and click events from the finger on specific buttons, and similarly for the desktop we wait for clicks on the mouse. It is interesting to note that each application window is its own object and the communication between them is called pseudo-events. Also it was surprising to notice that the main section of the code was pretty small and didn’t have anything important in it. Most of the code for interactive windows is in the event handling section of the code, and the user has complete control of the flow of events based on the interaction with the mouse.
Sara LaVigna 11:54, 27 September 2010 (PDT)
It was interesting to learn why Macs doesn't have multitasking, and instead have queues of events. In the beginning of Macs, since only one application could be run at once, the architecture was much simplified because everything was event driven and mouse motion events were easier. However, this can be resolved by generating an event every time the mouse changed position. Also, I didn't realize that object oriented programming languages like Java were used in interface event handling but it really makes sense to use abstract classes with the basic methods that connect to the windowing systems and have subclasses. It seems like object oriented models make it eaier to deal with communication between objects because it just needs to have an encoded method with the event and parameters of the other information.
Adam Vogt 11:59, 27 September 2010 (PDT)
I think that an interesting part of this reading is that the Input Events section is dominated almost entirely by the mouse. While the mouse is still an important input method when someone is using a PC its importance has been declining, and will likely continue to decline as newer input methods mature and become more common. Touch screens are becoming increasingly more common, and there are several similarities between touch events and mouse events but there are several distinct differences. For example the concept of mouse-enter and mouse-exit doesn’t have an application in a touch environment. This was actually a complaint made by Steve Jobs against adding Flash to the iOS operating system. Since Flash was designed for to support mouse "rollovers" and touch environments don’t use this type of event.
Anthony Puccinelli 12:01, 27 September 2010 (PDT)
Reading through this article, I was struck with how many of my friends prefer using Linux distributions over more "User-friendly" Operating Systems like Mac OS X. The key difference between the "programmer-friendly" Linux and the "User Friendly" OS X seems to be that the former is predominantly controlled through good old-fashioned text input which is parsed and executed accordingly and the latter is controlled predominantly through clicking on easy to understand visual widgets and images. This text argued that the gui-based way complicated things because the code now has to worry about juggling a lot of different things the user can do that they couldn't before. However, I would argue that once this foundational, OS-level work is done (managing all the different ways a user can resize a window, click on things in different orders, etc.), gui-based applications actually let you have more restrictive control over what your user can do. Given a text input box, a user could type almost ANYTHING, but with radio buttons/drop-down lists/etc. they only have a small set of actions they can choose and thus your code doesn't have to deal with receiving and responding correctly to as many "incorrect inputs".
Sung Ma 12:08, 27 September 2010 (PDT)
After reading the article, I was left with some things that I would like to talk about regarding the user interface and experience. Personally, I believe that the user interface is an important part when using any kind of electronic. The reading talks about the windowing system and some input devices. It was fairly easy and understandable but interesting because I have never thought about this system in depth or in detail. It was interesting to see the windowing system having root window with tree-like structure and input devices working in accordance with the system. Also, the embedding of one application in another was interesting as well. I agree with the article that this functionality has lot of potential when developing some system.
Arthur Huang 12:17, 27 September 2010 (PDT)
I never really thought about how smart it is for the right button of the mouse to open up a menu and allow the user to choose more options. It allows for multiple interactions to the computer given only 2 or 3 buttons from the mouse. The article also explains how windows and clicks are complicated and have to be handled delicately, and we see that when programming the apps in Android- each click needs something like an "onClickListener" function. Another interesting thing brought up by the article was why Apple computers do not use multitasking, but rather queues of events.
Edmundo 12:21, 27 September 2010 (PDT)
The first article really does a great job of overviewing the logic behind managing a windowing system. I especially appreciated the segment about networking windows applications and the different ways to handle that.
It was a bit discouraging to see how many times things were not discussed and rather left out for another section.
James Butkovic 12:29, 27 September 2010 (PDT)
Another UI-SE parallel: the event model and the observer design pattern. What separates the event model from something like a read-eval-print loop is that in the event model, the user is in control and the system responds, whereas in the latter, the system is in control and the user responds. It's interesting how often the screen needs to be redrawn when the user is interacting with it. Key board events are dealt with differently and are generally more complicated than mouse events.
Robin Liu 12:31, 27 September 2010 (PDT)
The article on the basics of event handling was very thorough and informative. The abstraction of the user interface into a tree allows the event handling to correspond to the object hierarchies rather nicely, as any single motion or action can have multiple meanings, depending on context. Any single action can be interpreted at the application level or the system level, and the designer needs to consider how the user would interpret and use any action. This not only makes for a complex state machine, but also a study in how user interface communicates the functions of certain user actions.
Tiago Bandeira 12:39, 27 September 2010 (PDT)
Once Mac implemented a windows based design Microsoft had to do the same because it truly made the computer accessible to the masses. The GUI design of a desktop instead of a command prompt is clearly much more inviting for the average person who has no technical experience with software design. The more these people used these early forms of Windows and Mac the more the conventions that these two companies designed had to be carried over to future generations of their products simply because the users did not want to relearn how to use these machines. Therefore, it was and still is important that any new conventions are well thought out since they are difficult to change once users become accustomed to them.
Danica Shei 12:42, 27 September 2010 (PDT)
It was impressive that developers came up with the double click due the limitations of the single buttoned mouse for Macs. It shows how you need to be creative with simple structures because most users are not going to take the time to learn how to use complicated devices. Also, similar to other articles we have read, it emphasizes the importance of creating UIs that must be very natural for the users to adapt and learn. This article also helped the tie the interactions between user interface and the much more complex software behind-the-scenes and clarify some of the problems we are tackling now - such as the need for handlers and listeners or motionevents.
Alan.choi 12:42, 27 September 2010 (PDT)
It was interesting to take a close look at the details of event handling, such as redrawing for a scrollbar. It's also amazing to see the complexity that goes into events and event-handling, such as the issue of double clicking, even though it wasn't really an event of its own (more like a special single click). Also, just from prior experience, I know how difficult it is to handle key events and create a UI for that with Java.
Bernard_Wong 13:32, 27 September 2010 (PDT)
Event handling is very important for a good UI design. Users need to know that their actions are being responded immediately. As there are more and more input methods, like keyboard, mouse, touch screen, shortcut buttons, applications need to listens to more and more events. Like assignment 3, for example, the proposed suggestion was to only prompt location bookmarking if the user touches around the center, and anything else that touches otherwise would be a scroll or zoom event. I can even find event driven ui designs in myriad of web pages, like in javascript, which listens on multitouch event, animation that is driven by user inputs, etc.
