Usability Inspection Methods

From CS 160 Fall 2011

Jump to: navigation, search




Discussion Questions

  • In terms of prototyping tools, (Flash vs. Eclipse/Android vs. a set of web forms browsed from an Android device) which do you think would be best for the "T"-shaped prototypes Nielsen describes?
  • From the 10 heuristics on Nielsen's list (which are for PCs), is there anything that is not very relevant to mobile apps? Anything that is conspicuously missing?


Please put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.

Huan Ji 17:02, 21 September 2011 (PDT)

The concept of usuability engineering surprises me a lot since I never learned it from my engineering design. I know that a design should be based on some survey, but not so systematic. The knowlege of usuability engineering should help me a lot in the future design, especially the prototype and heuristic evaluation. As for the "T" shaped prototypes Nielsen describes, I will say the android/elipse will match it better even though android is a time consuming and not a perfect process. The android will "reduce the level of functionality and result in a user interface surface layer" and each level will go deeper to the features and should implement the full functionality which we choose. As for the flash, I don't have experience about it, but it seems to be similar. Webforms will have more complex function even it has simpler level.

From the 10 heuristics on Nielsen's list (which are for PCs), I think, "help user recognize, diagnosis, and recover from errors" is not very relevant to the mobil apps. Since we define the "mobil apps", the "mobil apps" should be passive and convenient, but help user tackle the errors is somewhat professional and active. The 10 heuristics ignore the convenience.

Wei Jiang 14:17, 21 September 2011 (PDT)

Using Flash to prototype will give an idea of how the application is supposed to work. Depending on the budget and situation, Eclipse/Android leans more toward initial stages of development, whereas web forms would be very brief and design based, helping flush out big ideas.

Help and documentation doesn't seem too applicable for mobile apps since it takes a long time to read through. It's more helpful to aim for intuitive design that gives hints while you learn your way around it. Everything else seems very relevant to mobile apps, especially user control and freedom and minimalist design.

Ian Sarmiento 14:29, 21 September 2011 (PDT)

Flash is good for prototyping the the top of the T, while Eclipse/Android is good for the body/stem. A combination is required because there's no tool that can handle the implementation of a wide variety of features at a strong depth of functionality - multiple protyping tools are required. This is not a bad thing - this allows us to pick and choose which tools suit us best for whatever we're doing.

One of the heuristics that seems out of place to me is error recovery, given that it already mentioned error prevention - especially with a mobile devices, errors shouldn't pop up because the interface needs to be simplified as it is.

Frank 11:46, 21 September 2011 (PDT)

It seems like to truly implement a holistic T-shaped prototype, you would probably need to use both Eclipse and Flash, because Flash seems to be way more useful for horizontal prototyping, in that Flash is way more graphically based while Eclipse and hard coding is exactly related to implementation. Of course, it makes sense that what you prototype with has something to do with how you actually plan to implement your solution. For example, if you were to be making a flash game, it would probably not make too much sense to use a web form to prototype it.

In terms of the heuristics on Nielsen's list. It seems that the ones that are the least relevant to mobile development are accelerators for experts and visibility of system status. While it might be important to constantly know of the state of a PC process, space comes at a premium when developing for a mobile user interface. Similarly, simplicity is also important for mobile developers because input interfaces tend to be awkward and touch directed. Having a ton of shortcuts for experts does not make too much sense because you only have a few ways to input commands to the interface. Some heuristics that might be missing, or not emphasized enough, include minimalism and easy recovery support. Phones need to always be working as phones so when a program fails, a phone still needs to be able to make a call or receive one. That makes cross program protection and abstraction barriers very important.

Eric Shih 18:26, 20 September 2011 (PDT)

Even though usability engineering is thought to be expensive, I find it hard to believe that companies would be willing to forgo such an important step in the creation of a product. Without usability feedback from the target user group, how can a company be sure that they will not be spending more in the future to make up for design flaws that they did not discover early. I feel that even with the costs that usability engineering should be the front of engineers' and product owners' minds, and that there should be more ideas on how to decrease the costs, similar to the discount usability engineering approach discussed. As stated in the last paragraph of the Guerrilla HCI article, I agree that people have to run a user test and see with their own eyes the difficulties normal people may have running test software in order to truly understand how valuable usability engineering is.

The idea of using 3-5 test users and the discount user testing curve stuck with me, as well as the idea of using scenarios to create cheap, tailored, partial prototypes. One should also have clear goals for usability engineering work, and not just go in blindly and expect results.

I found the point about using multiple, independent individuals to perform their own heuristic evaluation before aggregating their results to be a key takeaway. The result that some problems were easier to find on running systems than on paper prototypes because people can just go to the next page with paper prototypes was also very interesting. Heuristic evaluation and User testing should be used as supplements to each other. Using the mean of a set of severity ratings from three evaluators is good enough for many purposes, according to Nielsen.

The technology transfer article talks about how a good usability method should be flexible and applicable to products in various stages of the product lifecycle. Also, in order for a method to gain popularity and be used as much as it should, it has to have advocators and exposure because people will tend towards what they have heard about and know, even if there are other good methods out there that they should be using more, but have not yet heard much about.

Hussein Omo Kadiri 14:08, 21 September 2011 (PDT)

Having worked with all three I would pick the Flash though it might be complicated to use but it works best when one wants to do the Horizontal prototype to sample different features because of Flash’s many features. It also works well with the Vertical Prototype because Flash is powerful enough to prototype a feature to as much detail as one would want it to.

From the 10 heuristics, I won’t say there is anything that is not relevant. What I would say is that the heuristic about “Recognition rather than recall” might be harder to implement on a mobile device than on a desktop because of the size of screen constraint.

Warren He 20:09, 20 September 2011 (PDT)


Obviously, I'm just going to pick the one I'm best at. Web forms.

To me, the Flash authoring tool is nice for graphical layout and stuff, but it's awkward to make interactive prototypes.

Android is troublesome, because it takes time to compile a project and run it on a phone.

Besides, shouldn't you be picking a platform based on your target audience and intended product?


  1. Visibility of system status: good
  2. Match between system and the real world: good
  3. User control and freedom: good
  4. Consistency and standards: good
  5. Error prevention: good
  6. Recognition rather than recall: bad, since it takes up space
  7. Flexibility and efficiency of use: good
  8. Aesthetic and minimalist design: good. Not just for mobile, but why minimalist?
  9. Help users recognize, diagnose, and recover from errors: good
  10. Help and documentation: culturally unusual to have separate documentation

It seems like there's nothing about making common tasks easy.

Terri Yeh 17:41, 21 September 2011 (PDT)

1. It seems that Flash is better for horizontal prototyping, while Eclipse/Android is better for vertical prototyping. Horizontal prototyping focuses on getting a broad view of the entire system, and flash can simulate that with less effort from the programmer than Eclipse/Android. On the other hand, vertical prototyping focuses on the elaboration of a single function within the system, where Eclipse/Android seems to be better suited to develop that.

2. From the list of 10 heuristics, I think the least relevant would be the accelerator. Although it is a good idea to allow more experienced user to speed up their task performance, there's limited space on a mobile device for the extra feature, and most well-designed mobile apps are already pretty good at minimizing task complexity anyway. All the others are still applicable, although some might be harder to implement on a mobile device

Leslie Chang 21:17, 20 September 2011 (PDT)

I feel that the prototype should be the closest to the actual platform used so the answer depends on what platform the application is being written for. For example, if you are designing a video game, it does not make sense for you prototype to be built on a web form. The prototype should be as close and possible to the final product.

The ten usability heuristics outlined by Nielson are still relevant for mobile apps, especially the aesthetic and minimalist design. Since real estate space on mobile phones or tablets is limited, the designer must take into account making the app readable and not over-crowded on the screen. In addition, one heuristic not taken into account is the time it takes for the program to load and compile. Because mobile phones have less processing power, you do not want to make a program that requires a lot of power to run because the program will be slow and the phone's battery will lose power fast.

Filbert Hansel 21:24, 20 September 2011 (PDT)

  • I think Flash can be very useful to provide a prototype based on simple scenario, especially the earlier tool (ActionScript 2.0) that relies on graphic more than structured code. This helps many user interface designer that may not have adequate technical background to create an essentially working prototype without worrying so much about the technical aspect of the development. It is important to take into account that the most creative mind may not have had the training to use Android SDK and web-forms for prototyping, but is most likely to have the graphical idea down; hence pro-Flash.
  • User control and freedom, as in the support for undo and redo, do not seem to be of relevance for mobile apps due to the simple and minimal focus of the platform. Recognition rather than recall also do not hold on massive options due to the more limited real-estate. There does not seem to be anything conspicuous missing.

Katelyn Sills 21:41, 20 September 2011 (PDT)

I think the set of web forms browsed from an Android device would work. It seems like the important thing for most companies is to just do some sort of evaluation, even if the number of users or experts evaluating is small, and the prototype is low-fidelity. I find trying to iteratively prototype in Eclipse to be really slow, considering that you have to wait for everything to load before you see your changes. Web forms seem like they would be easy to alter and a pretty good approximation of the actual interface.

All of the 10 heuristics seem very important for mobile apps, especially a minimalist design, considering the limited display space of a mobile device. I think one thing that is missing for mobile devices is a measurement of how well the app blends with the user’s environment. By this, I mean that a mobile app should be able to be used quickly and then put away quickly. Unlike a PC, where a user may sit down and not leave for hours, a mobile user is on the go and cannot take the time to take several steps to “get into” the program.

Jonathan Tien 21:52, 20 September 2011 (PDT)

  • In terms of prototyping tools, (Flash vs. Eclipse/Android vs. a set of web forms browsed from an Android device) which do you think would be best for the "T"-shaped prototypes Nielsen describes?

I feel like a flash would be good for building the 'horizontal' prototype, because its easy to rapidly layout some screens a build simple transitions using static images to simulate an overall feel for the interface. For a 'vertical' prototype, probably best to build it in Eclipse with the Android SDK, because you can more or less fully develop the feature and pretty much exactly simulate what it would look like in the end result. Web forms don't give you enough flexibility or power to actually simulate an interface, I don't think they are appropriate for anything (even a low-fi prototype using paper is probably better, in my opinion)

  • From the 10 heuristics on Nielsen's list (which are for PCs), is there anything that is not very relevant to mobile apps? Anything that is conspicuously missing?

No, I feel like these 10 heuristics are all applicable to mobile app design, except maybe accelerators. Its harder to create custom actions on a mobile app, since there are few controls (no keyboard shortcuts, less screen real estate, etc).

I'm not sure I would add another heuristic, but I think a few important thing to note are: - pressable areas/buttons should be large and distinguishable to avoid errors - since mobile processors are slower, you may need to use some tricks to make things seem faster than they are (load static images prior to loading actual UI elements) - have clear navigation elements that make it easy for users to tell where they are and how to get to and from different screens

Dustin Shean 22:53, 20 September 2011 (PDT)

Web forms browsed from an Android device is the best for “T”-shaped prototypes. By providing the information on the actual Android device the user is still able to have the feel of using the device, without imposing an expensive cost onto the design teams. Especially since the article was concerned with the shortcuts that companies take in order to decrease costs, web forms is the best option. Programming the design should wait until a later stage in the prototyping cycle because the cost of not only getting the initial prototype is more expensive, but the future fixes to the design after testing are exponential.

For the most part all of these 10 ideas apply to mobile phones. The only one I would alter is the help and documentation heuristic. Most Android applications are not as complex as some PC software/applications and the screens are a lot smaller; therefore, providing a help screen that engulfs the screen may not be the best choice. Instead I would propose a tutorial for the first time using the application.

Sakura Reyes 23:16, 20 September 2011 (PDT)

Of the options given, it seems clear to me that simple web forms are the most apt, with Flash perhaps close behind if the team already has a knowledgeable and skilled Flash programmer. In the latter case, producing a simple Flash application can be very fast and simple, although if such an experienced programmer is not present then the simplicity of creating web forms makes it the better choice. By comparison, developing on Android requires a significant amount of overhead (compilation time and coding), although extremely simply user interface mockups might be constructed with widgets and existing templates. In this regard using Android to prototype is similar to Flash, in that an experienced Android programmer could make the platform fast and simple enough to be a very effective prototyping tool. For the extremely simple ‘scenario’ prototypes listed, even paper mock-ups or drawings might be appropriate.

In terms of the heuristics, most seem quite applicable but there is a clear conflict between ‘minimalist design’ and ‘recognition rather than recall’ – given the smaller form factor and limited real-estate on mobile devices, thought must be given to using the space efficiently. It is necessary to have good visibility and feedback, but also to avoid clutter. A notable missing heuristic might be to emphasize ease and accessibility of common tasks; a mobile device is often used ‘on the run’, and users will want to be able to use their most commonly-accessed features without having to do much navigation.

Manduo Dong 00:11, 21 September 2011 (PDT)

I think Eclipse/Android fits the description of this T-shaped prototypes Nielsen describes. For a particular scenario, we can add features (functions) to it (Horizontal Prototype) or fully develop the feature (function) (Vertical Prototype).

All 10 heuristics seem to be very important to mobile apps. If I were to be picky, I would choose user control and freedom as something that is not very relevant to mobile apps, because all the mobile apps are fairly independent to each other and there is already a home button that act as an emergency exit. Therefore, there is no need for the app itself to implement another exit. Also, for mobile apps, there should be a heuristic that measures the compatibility between the app and the device. I know a lot of games were originally designed for computers, and then were implanted to iPhone and iPad such as Final Fantasy and Street Fighters. However, some games ignored the limitation of mobile devices. As a result, the on-screen joystick is not that "playable" compared with keyboard and mouse.

Jonah Turnquist 23:31, 20 September 2011 (PDT)

I think drawings are fine for horizontal prototyping. This is because horizontal prototyping does not require the UI to work, it must only show what it maybe it is supposed to do. For vertical prototyping - probably use whatever tool you are going to create the app in at the end. This should allow you to fully implement a said UI element vertically.

I strongly feel all 10 heuristics are totally relevant to mobile applications. I cannot think of anything to add to this list: the 10 already listed are worded to be pretty broad. I looked to see what other students said for this, and feel their suggestions are actually already included in at least one listed heuristic.

Josef John 23:55, 20 September 2011 (PDT)

I don't know much about prototyping tools, but if the app is going to ultimately run on the Android, then it might make the most sense to have the prototype use Eclipse/Android. Although there should be different stages of prototypes. Maybe start on paper, move to flash/web forms. But ultimately, I think most of the usability testing should be done on a prototype that is closest to the actual end product.

All the 10 heuristics seem good for the Android except the last one: help and documentation. I don't think documents help the majority of users very much anymore. Instead, as long as there are online forums where users can ask question if they run into problems, that seems a lot better than looking through a manual trying to solve a problem that may not be listed. Users can then always rely on getting help the same way no matter the problem.

Konigswagger 23:57, 20 September 2011 (PDT)

  • I think a set of web forms would be best for the T-shaped prototypes Nielsen describes. Web forms are easy to learn/make, quick (no need to compile), and easy to modify/adapt to proposed design changes. Additionally, there are so many plugins/tools/pre-made style sheets out there that a person without any experience can make a prototype. The plethora of WYSIWYG software makes prototyping trivial.
  • All of the heuristics on Nielsen's list are relevant to mobile apps, though some to a lesser degree than others. Flexibility and efficiency of use needs to be thought out carefully because done wrong, it might actually make the application more complicated. Done right, ex. Cydia for jail-broken iPhones: User, Developer, Hacker options, the flexibility is a huge plus to the end user. A button for SKIP tutorial in a game/application is something that is simple to implement, and for most applications, would positively improve the user experience. One thing that I might add to the list is to ensure buttons/UI elements are easily accessible. For instance, on Android's Dolphin browser, whenever you try to click on the bottom left of the browser, you trigger a prompt for drawing a gesture when you might actually be trying to click on a link located on the bottom left of the page.

Sylvia Lin 00:00, 21 September 2011 (PDT)

I think web forms are the easiest to implement out of the three, and the best for horizontal prototyping. A web form can be easily set up, and can represent the most basic layer of the user interface. Additionally, some functionality can be added to accomodate vertical prototyping. For something specific to vertical prototyping, a simple Flash application can be created for a very basic prototype. However using the Android to prototype might be more efficient if the developer plans on using Android for the final product. Overall though, web forms would be the most efficient for prototyping, even if it's functionality is limited.

All 10 heuristics are relevant to mobile applications, though some are probably more relevant to mobile apps than to pcs. One heuristic that especially applies to mobile apps is the aesthetic and minimalist design. Mobile apps are created for much smaller screens, and thus have less space which much be used more efficiently. User control and freedom are also important, because it is easier to make mistakes when trying to access buttons or type on a smaller screen. The way that mobile products are set up makes them more prone to causing user errors just because buttons are harder to focus on.

Januardo Kusuma 00:11, 21 September 2011 (PDT)

A set of web forms browsed from an Android device would really fit best for the "T"-shaped prototypes Nielsen describes. Even though in general prototypes should be as close as possible to the final product, testing can be done in many different ways. Thus, it seems that the easiest and cheapest way to create prototypes is, based on the three options, web forms browsed from an Android device. All we need to do is just modify it and we can start showing it to the testers. It would be kinda hard to navigate through, but it does the job and will not cost as much as the other options.

Everything (10 of them) that is listed there are relevant to mobile apps. Every single aspect of an app has to be made easy for users to use and understand, as well as easy for them when they need help. I cannot think of anything to add to the list.

Manduo Dong 00:12, 21 September 2011 (PDT)

I think Eclipse/Android fits the description of this T-shaped prototypes Nielsen describes. For a particular scenario, we can add features (functions) to it (Horizontal Prototype) or fully develop the feature (function) (Vertical Prototype). Testing can be done with functions one by one. (I am a little confused about this model though, I will take notes on the instructor's highlights about this one.)

All 10 heuristics seem to be very important to mobile apps. If I were to be picky, I would choose user control and freedom as something that is not very relevant to mobile apps, because all the mobile apps are fairly independent to each other and there is already a home button that act as an emergency exit. Therefore, there is no need for the app itself to implement another exit. Also, for mobile apps, there should be a heuristic that measures the compatibility between the app and the device. I know a lot of games were originally designed for computers, and then were implanted to iPhone and iPad such as Final Fantasy and Street Fighters. However, some games ignored the limitation of mobile devices. As a result, the on-screen joystick is not that "playable" compared with keyboard and mouse.

Konstantin Rud 00:30, 21 September 2011 (PDT)

I think generally speaking each tool has situations it is better suited for and no tool can always be better than another tool at a particular task, unless one tool is completely horrible. That said, the same applies for prototyping, it depends on what one is prototyping and how they are planning to implement the features or the functionality. However, a surface evaluation would make me lean towards using web forms to browse features of a device as this seems to be somewhat more simple and use flash or android for a functioning demo of the software.

For the ten Hueristics I think they all pretty much apply to both PCs and mobile apps, in fact I have observed almost all of these in good designs and have noticed a trend towards these heuristics. The few exceptions are that aesthetic and minimalist designs are not always feasible with PCs, though we are seeing a trend towards this in recent computer interfaces, and modern computers are still pretty bad at helping users diagnose and recover from errors. A possible heuristic not mentioned is to keep "important" OS activities hidden and non-obtrusive. An example of this would be system updates in Windows Vista, which have become much more annoying in Windows 7 and most of these updates seem irrelevant for example: do I really need to be interrupted to install Internet Explorer 9? I don't even use IE.

Kevin Chung-Kai Wang 00:30, 21 September 2011 (PDT)

I've never used those prototyping tools to prototype before so I don't know how they work... I think flash allows you to lay out things, if that's the case then just like paper mockups, it should be good enough for both horizontal and vertical prototyping. You can draw out the most significant points of the different features you plan to implement, without needing to worry too much about the details that goes behind its functionality, so that's good for horizontal prototyping. You could use it to storyboard and focus on a single feature's many states, so that's good for vertical prototyping.

I think all 10 heuristics are applicable for android apps. User control and freedom & minimalist design are important because android apps have small screens so people might accidentally touch stuff they didn't mean to touch, and display space is limited and needs to be conserved. The rest are useful for any applications, no matter what platform. I suppose help and documentation would be the least necessary, though, since most android apps I've seen are so simple that simple labels have been enough to use them. But I don't see anything wrong with keeping documentation somewhere just in case, maybe on the internet. So long as it doesn't waste unnecessary space on the actual device, since storage capacity may also be limited.

Jie Min Wong 00:34, 21 September 2011 (PDT)

For horizontal prototypes, which only involve building the surface of the user interface, it is best to use a set of web forms from an Android device. The main reason is that web forms are relatively easy to implement compared to Flash and of course, Eclipse/Android. Also, with CSS3, HTML5 and Javascript, we can easily mimic the look and feel of the application, which is all we need for horizontal prototypes. For vertical prototypes, it seems to me that the only viable option is Eclipse/Android because full features have to be built. Although some of the same functionalities could be mimicked using Flash or web forms, only Eclipse/Android can produce a prototype that most closely resembles the actual interaction of the application.

I think all 10 of the heuristics make perfect sense for mobile apps. However, I think ‘minimalist design’ should be given a stronger emphasis for mobile apps because of the limited screen real estate of mobile applications. For example, a mobile app should have much fewer controls than a desktop application. There has to be just one way of doing things and not provide too much options to users.

Chetan Surpur 01:12, 21 September 2011 (PDT)

The T-shaped prototypes include either a vertical or horizontal prototype. For vertical prototypes, a set of web forms would be appropriate, because it is easy to develop complete functionality in a web interface. For the horizontal prototype, which just gives the user a feel for how the product would work, Flash works well, because it makes it easy to rapidly prototype a user flow experience, though it is hard to actually get functionality working.

Of the 10 heuristics, I think only documentation and help is something that won't work very well for mobile apps, since those must try for a rapid, agile experience without trying to slowly teach the user how to use the system. Help should not even be needed, since the interface should be so small and simple and intuitive that the user should be able to use it immediately, or with just a few on-the-fly pointers. Something that is missing from the 10 that in my opinion is important is beauty of the interface. Though it is not strictly a requirement, it can greatly improve the user interface.

Jay Chen 01:20, 21 September 2011 (PDT)

I think for the T-shaped prototypes, horizontal and vertical prototypes should vary in their implementation since the goal is vastly different. I think for horizontal prototyping, Flash would be preferred. Flash allows a person to quickly create frames that are usable. The interface created by flash is quick enough that a broad array of features and screens can be implemented at a good enough quality to give the user and idea of how the interface would work. Since flash has limited functionality, it would not work so well for vertical prototyping. For vertical prototyping, I think that Eclipse would be the best solution. Eclipse is a powerful IDE that allows a person to build a stable back end that can implement all the features within an app. It's slightly slower, but is easy to adapt to once completed. I think if we wanted to do both horizontal and vertical, then I would choose webforms. It's quick enough to pull out the necessary frames to give a general idea of the app as well as have enough functionality to implement a feature fully. Based on what a person is trying to achieve, they should choose Flash, eclipse, or web forms accordingly.

I think all 10 heuristics would work well when applied to mobile. Generally, these concepts can be easily applied to any program including mobile since mobile share many similar traits. However, mobile is unique in its size as well as ubiquity in our everyday lives. I think for mobile, there should be a heuristic to evaluate the simplicity/usability of an app and a heuristic to evaluate the degree of integration with daily life.

Harvey Chang 01:34, 21 September 2011 (PDT)

  • I think that for the horizontal portion of prototyping, web forms may be a good choice since they let the user do a general layout of all the various features without getting too deep into the functionality. Conversely, for vertical prototyping, whichever prototyping tool the designer is most familiar with is probably going to suit them well. For myself, Eclipse/Android would allow me to most easily flesh out functionality for a particular feature. That being said, however, I believe the best tools for prototyping depends on the nature and constraints of the project at hand.
  • The 10 heuristics for user interfaces described in the article all look to be relevant to mobile devices to some degree. These heuristics can be applied to whichever platform to be developed on. If I had to choose one that is least relevant to mobile devices specifically, then I would probably choose the help and documentation. Mobile devices should have simple and intuitive interfaces, and they should not have such a volume of features or options which necessitate extensive documentation. I'm not saying documentation is useless; I just feel that it does not stand out quite as much as the other heuristics when it come to mobile devices.

Jiahao Li 15:37, 21 September 2011 (PDT)

  • Flash fits the "horizontal" category. It focuses on the visual effects of the user interface. Eclipse/Android tools fit in the "vertical" category as they allow deeper development of certain features and functionalities.
  • From the 10 heuristics, I would say all of them are also the basic ideas about design of mobile apps. What's missing is the screen element of mobile phone. As mobile devices generally have a relatively small screen, a very central problem is to help users focus more on the essential parts and avoid crowding the screen.

Ivan Motyashov 01:54, 21 September 2011 (PDT)

  • For horizontal prototyping, web forms seem like the most intuitive solution, since they allow for relative faithful reproductions of the intended interface and are much easier (and quicker) to work with than both Flash and Android/Eclipse, making them the perfect option for demonstrating features without implementing too much functionality. For vertical prototyping, it seems, one would have to go with Android/Eclipse, as it's certainly a better solution for implementing (semi)complete functionality and is overall a more powerful tool, as it may provide the developers with tools not available in Flash (and certainly not easily available in web forms).
  • All of the 10 heuristics listed by by Nielsen appear to be relevant to mobile apps. In particular, it seems like error prevention and aesthetic and minimalist design are especially good heuristics for these purposes. Help and documentation, as well as help with error recovery may have slightly lower priority on mobile devices, since the focus ought to be (in my opinion) to eliminate difficult / error-prone situations as much as possible, particularly on these mobile platforms. A heuristic that may be relevant uniquely to mobile apps is "ease of interaction on-the-go" or something of the sort -- how easy is it to use the app if one only has very limited time, or if one is walking/standing/in an inconvenient situation.

Christopher Chen 02:07, 21 September 2011 (PDT)

  • Web forms seem to be more desirable for horizontal prototyping, Though for vertical prototyping the best tool would be the one the designer is most comfortable with. Personally I would prefer Eclipse/Android to make the full use of the hardware Android is operating on, as well as add in additional features web forms would not be able to have. This isn't to say that I would never use web forms, as each project and design case has its own constraints and specifications, and it is good to know all of the tools to find the right fit solution to the problem.
  • The heuristics for UI look to still be relevant to mobile devices nowadays, especially 'Aesthetic and minimalist design'. One thing about going mobile is that the screen's real estate will be small, as currently we do not have a better way of displaying a UI than through a screen. This limits the amount of widgets or apps we can fit on a screen and minimalist designs help maximize the use of our allotted space.

Praneet Wadge 03:54, 21 September 2011 (PDT)

  • It makes more sense to use web forms for the horizontal component of prototyping, since they are quicker to create and can demonstrate with enough praticality how an interface or the workings of a program function. When you want to conduct vertical prototyping to produce a product more or else actually functional and useable, it makes more sense to use Android/Eclipse. These tools are far more powerful and actually used in industry to create real world products that are used and implemented by customers; hence, when creating an in depth vertical prototype, it makes sense to use tools that can help you make a working powerful product.
  • Interestingly enough, help and documentation seem to be having a smaller and smaller role in today's mobile devices. This is due to the smartphone/tablet phenomenon that implicitly says devices should be automatically intuitive and simple to use. Because of this, documentation and help functions are relied on less and less by consumers since most programs on mobile devices are programmed from the beginning to be easily useable out of the (metaphorical) box. This is not to say that help and documentation do not exist and are not important, but rather that most people like apps that are familiar and simplistic enough to follow through. One thing that may be missing from the list is Customizability/Sharability, since there seems to be a general push toward the trend of customizing your own interface or having the ability to instantly share your status/views with a network (Facebook, Twitter etc)

Phillip Carpenter 05:13, 21 September 2011 (PDT)

  • I think that web forms are the best for developing on T shaped prototypes. These are usually the easiest to create, and require less overhead than developing something in Flash, which can be long and tedious, or developing something in Eclipse, which can have too much learning overhead. The Web form design is easy to pick up, and allows for fast prototyping and development, which is very important in these "T" shaped prototypes.
  • I feel like all of the items in Nielsen's list can be argued as being necessary and applicable for mobile apps as well. In general it could be argued that all of those items apply to mobile devices as well. But if you really wanted to find one to remove, I would say the Flexibility and Efficiency of Use could be taken out. Since mobile apps are usually smaller, and might require more levels of tediousness for consumers to play, flexibility becomes less of an issue, and the focus is more on designing something that is fun enough to play that people will overcome playing it on their non game-geared mobile device with a small screen.

Nancy Wang 06:10, 21 September 2011 (PDT)

Out of the three, I think Eclipse/Android is best for the T prototypes; the program is equipped and aims to create realistic prototypes to be tried out for the Android itself. Running on the Android emulator you can quickly get results to use to improve the design. I have played some games created through flash; they are normally easy to use yet simplistic, so to me Flash is more vertically-oriented. Web forms are good for horizontally-oriented prototypes since you can easily demonstrate all sorts of features.

Pretty much all 10 on the heuristics list seem relevant to mobile apps. My mobile device keeps me up to date on its status; right now mine has been informing me of the simcard error for the past few days, going to have to send it in to get fixed :(. The apps are easy to use and not too complicated. I suppose the one thing on the list that seems the least relevant is help and documentation since that info might take up too much space in the phone's short-limited storage. I can see that being stored on a website somewhere so the phone can look it up through the Internet app easily.

Ieong Chon Lo 08:52, 21 September 2011 (PDT)

I think web forms and Flash are more suitable for horizontal prototypes, however; web forms is easier and cheaper to develop the interface or prototypes. For vertical prototypes, we need to implement the features and real prototypes. Therefore, Eclipse/Android becomes the most powerful tool to build the real product. Designer can easily to do the testing and improvement.

All 10 heuristics can apply to mobile apps in similar way, and some of them are important for mobile apps. Especially, ‘minimalist design’ can help to consider how to use the space efficiently due to the small screen size of mobile devices. A simple and fewer controls interfaces are good for mobile apps users, however; simple doesn't mean it can avoid some of the functions.

Kate Feeney 09:51, 21 September 2011 (PDT)

  • When doing a "T" shaped prototype Eclipse/Android would probably be the best tool. This is because when doing vertical prototypes the number of features are reduced but the features you have you want to be fully implemented. The easiest way to fully implement features correctly would probably with Eclipse/ Android. Also if you already have a featured completely implemented in Eclipse/ Android they will not have to be recoded for new versions. Also surface layer interfaces are simple to do with Eclipse/ Android and having the emulator or being able to load the app on a device can greatly help in the testing process.
  • Of the 10 heuristics on Nielsen's list they all seem in someway relevant to mobile apps. Since they are all about making the apps simpler and easier to use they apply to both PC's and mobile apps. One heuristic that might be less relevant to mobile app is help and documentation. This is less relevant because people are not very likely to spend the time to read documentation or to really learn how to use an app. It is much more important that the app is usable without documentation. But help features might be more relevant.

Peter Tsoi 10:07, 21 September 2011 (PDT)

Flash provides an ideal mix of interactivity with quick turnaround times for the T-shaped prototyping described by Nielsen. Not only does Flash integrate well with other Adobe products like Photoshop and Illustrator which are commonly used to create screen assets and UI sketches, but it provides a way to show both the states and transitions previously outlined and designed in the storyboarding phase.

The 10 heuristics that Nielsen lists as rules of thumb for UI design are generally applicable to mobile apps. However, because of the reduced screen real-estate, sacrifices to user freedom and should be weighed against minimalist design in order to prioritize what the user may want to do. It is still important to offer "emergency exit", undo and redo, but imagine how painful Microsoft Word's drop down menus would be on a phone.

Guoxiong Xie 10:27, 21 September 2011 (PDT)

In terms of T-shaped prototypes, I think a set of web forms browsed from an Android device would work. With web forms, different features and functionalities of an applications can easily be developed. Compared to Eclipse and flash, web form is easier to start and less tedious to develop a prototype.

From the 10 heuristics on Nielsen's list, I think all of them are relevant to mobile apps. Heuristics applied to PC app design should also be applied to mobile apps. One thing that is missing in the list would be visibility control. Since the display of a cellphone/tablet is relatively small, the visibility is more constrained. Together with the zoom-in/out feature of the phone, mobile apps option should have different level of details that allows the users to navigate.

Jessica Pan 10:53, 21 September 2011 (PDT)

In terms of the T-shaped prototype, I think that Flash would be the best. It is part of Adobe that also produces Illustrator, Photoshop and Dreamweaver and thus is uniquely situated to take advantage of its affinity with these products. Flash integrates well so when creating screen shots and UI sketches, it provides a simplier way to shop various states detailed in the prototype.

10 Heuristics All 10 heuristics are relevant to mobile apps. The major problem would be dealing with screen size and amount of information that could be displayed at the same time.

Michael Pack 11:02, 21 September 2011 (PDT)

  • For horizontal prototyping it is important to get most of the interface layer while vertical prototyping focuses more on functionality of a few features. For this reason it would make sense to use the final development software to implement fully functioning features and rapid development software like flash to implement horizontal prototypes of the interface.
  • Most of the heuristics were applicable to mobile applications with maybe the exception of flexibility and efficiency of use as well as documentation. Short cuts and hot-keys are difficult to implement on mobile devices without making the interface overly complicated and documentation should be unnecessary if the interface is sufficiently intuitive. An item missing from the list would be how well does it work on-the-go or in the environment of the mobile device.

Liu Chao 11:09, 21 September 2011 (PDT)

To show pictures and prototyping, flash is useful, case it is easy to gives a broad pictures to show to the customers. Web tools maybe as useful as well, but from my personal experience, the interface is kind of boring. It maud good at show function of one part of the full system. To use android or eclipse to make prototype is almost meaningless, because the point of give prototype is use least cost to give most figures of the system, in contract, code in android or eclipse is a time consuming thing to do. Web form is a easy to implement, give a full function of one aspect of the system,which is good for a vertical pr prototype. In general, 10heuristics a are mostly relate to mobile app One problems for mobile device is that they are limited by the size of screen and because of that, each function should be more intuitive. The best condition is not 'people can find a lot of help information' but people don't Need to find any other information but just see the buttons and can understand what is the function

Evan Kawahara 11:14, 21 September 2011 (PDT)

  • In order to best achieve the "T"-shaped prototypes that Nielsen discusses, I think designers should utilize web forms. Nielsen's argument throughout the entire argument is that the usability engineering process and iterative design cycle are often associated with extremely high costs, but that these costs can be reduced to make the process very achievable. In this sense, developing prototypes in Eclipse/Android simply does not make sense. Rather than reducing costs, time, and overhead, this development method would take significantly more time and work than simple web forms. I think web forms are more realistic because the development of web forms is very quick and easy. In this sense it is perfect to develop for a large variety of scenarios, which Nielsen describes as the "horizontal" aspect of the "T"-shaped prototyping process. What makes web forms the best prototyping tool to achieve the "T"-shape then, is in addition to being able to create a number of scenarios quickly, browsing these web forms on the mobile platform can also simulate many of the same features, and in this way adds depth as well. Flash can also be a decent prototyping method depending on how much the developer is willing to invest into the prototyping process, but I believe that web forms are the most cost-effective method of prototyping.
  • I think that from Nielsen's list of 10 heuristics, the most prominent feature that does not suit mobile apps is the Help and Documentation principle. Nielsen writes, "may be necessary to provide help and documentation. Any such information should be easy to search." On a mobile platform, screen space and real estate are extremely limited, and therefore including a lot of help is slightly unrealistic, and providing separate documentation is even more unrealistic, as these apps are obtained virtually on-the-go, and users are typically not looking to waste time reading separate documentation or going through a lot of instructions before being able to use the app. Other than that, I generally agree with the other principles in Nielsen's 10 heuristics, but I would just elaborate that minimalism should be the guiding idea behind many of the other principles, although not explicitly stated. I think the other principles must always be associated with the idea that mobile apps are very limited in terms of display size, and this should be key in implementing the other principles so that space is not wasted or crowded.

Omar Rehmane 11:46, 21 September 2011 (PDT)

Android would be an excellent tool for the T-shaped prototype, because you can use the simulator to fully implement the functionality without even having a device. You can map out the UI very easily, and then do the vertical prototype for specific features, since the simulator will work even if the whole application is not fully implemented.

Everything on the list is definitely applicable to mobile apps to some extent, except for the documentation. Mobile apps live and die by intuitive use, so this part isn't necessary - it has to be understandable enough for people to use it without reading anything. As for what's missing, a good mobile app takes into account battery usage in its design and uses energy-efficient tasks as much as possible.

Aaron Eidelson 11:58, 21 September 2011 (PDT)

I believe that Eclipse/Android provides the best opportunity for T-shaped prototyping. It allows for a skeleton UI to quickly be put together (horizontal prototyping), but also provides a lot of room for fine-tuning and iterating on individual UI elements (vertical prototyping). It also allows the creator to insert arbitrary views (with arbitrary backgrounds) as place-holders for UI elements when trying to get the layout right.

The only heuristic I don't agree with is the final one, help and documentation. Few mobile apps have help systems and I think there's a reason for that - they don't work. People generally don't want to go through the work of reading documentation. I do, however, think a "getting started" tutorial is important in giving the user some context. I have commonly heard in the computer science world that you generally shouldn't have to comment your code, it should be clear enough speak for its self. I think the same applies to user interfaces. I think an additional heuristic for mobile apps would be clarity in purpose. When functioning with the scarce resource of screen space, an app must have a specific and unobstructed purpose.

Allan Yu 12:07, 21 September 2011 (PDT)

I think web forms on an Android device would be best. It would be easy to implement with a large amount of functionality, for as little development it would cost for the initial mockup. Having the mockup on an actual device without having to actually program it will also be beneficial in simulating the actual usage of the app.

The help documentation don't really apply for Android devices. Typically the apps designed mobile are small and are simple by nature. Help documentation exist, although it is less relevant to mobile apps since they are typically not as complex as desktop software. No mobile app I know spits out an "error".. they only crash.

Chien Ting Tang 12:18, 21 September 2011 (PDT)

The prototype tool is really heavily depends on the project. The web form has advantage that it is easy to use and show. The Flash is fast and fancy if the project has gotten a good Flash programmer. And Eclipse/ Android tools are detail and fancy. Hence, in my opinion, T- shaped prototype is best to use web form for horizontal prototype since it is the easiest. And other tools are good for verticle prototype as it need more details.

I think the ten principles are pretty well organized and thinkful. Even they are for mobile application design. I think the only thing that it is kind of missing is to make sure the future update is easy and not complicate.

Victor Krimshteyn 12:36, 21 September 2011 (PDT)

Horizontal prototyping (full features without the back end) would best be done on something like Flash because it would be fairly easy to implement to implement a full visual interface. Vertical prototyping (full programming for a specific section of a program) would best be done in Eclipse/Android because you can actually program the back end.

I would say that all ten heuristics are very relevant to mobile apps. The acceleration for experts section might be extra because mobile apps can and should support only so many features for the sake of simplicity.I guess for mobile apps you would also want heuristics that deal with the actual touch interface, as this can potentially be a problem.

Gong Cheng 12:42, 21 September 2011 (PDT)

I think flash will be the best option for the T-shaped prototypes, as flash provides a simple, quick, graphical approach to the prototyping, making it easier for the user to understand and use. It says in the article that "horizantal prototypes reduce the level of functionality" while "vertical prototypes reduce the number of features" (Nielsen). It seems that flash is the one that satisfies all requirements.

The items that I don't think necessary for mobiles are: Help and documentation. Help users recognize, diagnose, and recover from errors

Maybe one can add "easy to learn" to the list?

Jian Chen 12:44, 21 September 2011 (PDT)

I don't think there's the "best prototyping tools" for the "T"-shaped prototypes. Flash, Eclipse and other tools have their own strength and weaknesses (for example, Flash is more vividly appealing in the design process). But I don't think it's a good idea to consider the tools we are going to use for a specific product before knowing what exactly we are targeting. We should leverage the power of each tool only after we know what features/functionalities users want.

I think all of these 10 heuristics are good for Android development as well. I think "Aesthetic and minimalist design" is very important. For mobile apps, since we have a small screen, it would be better if we leave out those non-neccessary fancy layout and put the important things up front to the users. This heuristic strickly ties with other heuristics. If we have a good minimalistic design, we also acheive "efficiency of use", "visibility of system status, and "consistency and standards".

Deryu0502 12:53, 21 September 2011 (PDT)

  • graphics would be the feature while eclipse/editor/interpreter would be the function
  • the accelerator is not necessary since mobile apps are designed to be simple. However, latency and power consumption are something that was not addressed

Yongjin Jin 13:07, 21 September 2011 (PDT)

For the T-shaped prototypes that Nielsen describes, I think that a set of web forms browsed from an Android device would be the best for this. The main reason is that web forms allow for easy creation of GUI although not fully simulating the actual program, it could give an idea. The horizontal prototype requires full features to be implemented, and with web forms, its easy to set up different web pages for different features. As for functunality, it falls short. However, functionality can be simulated to a decent extent using web forms since the person can generally see the consequence of using a feature and what it does. So taking the T-model, the cross only requires a section of feature and for that section to be decently functional. This means that these simulations or testing does not have to be perfect but just give an idea of how these work and how it functions. Therefore, web forms which allow for wide variety of features while being capable of certain functions, is I think best fit for this T-shaped prototyping.

From the 10 heuristics, I think that "Recognition rather than recall" section is irrelevant. WHile others have its place and can be implemented, trying to apply this heuristic will jeopardize many of the other heuristics as there is only a limited space on screen on a mobile app. For example, applying this heuristic would require more widgets such as buttons and images, but doing so can possibly compromise flexibility, aesthetics, and make it hard to implement visibility of system status as the screen would be cluttered. If there is one thing missing, I would have to say that efficient widget placement and reasonable option overloading. Because there is such a limited space in a mobile device, I think the key to making it look appealing is to cleverly place minimal amount of crucial widgets first. Then, allow the user to access other options through a section full of menus or overlap some menu items so that while not being too confusing, allows a single widget to perform multiple tasks depending on the context of how the app is running.

Kim Nguyen 13:11, 21 September 2011 (PDT)

Of the options listed for prototyping, I think web forms are the easiest to use for horizontal prototyping. They are easy to code and displays a user interface layer well. For vertical prototyping, I think Eclipse/Android is best. It allows for full functionality implementation.

I think the ten principles apply to mobile apps also. Of the ten, perhaps "help and documentation" is the least applicable, although help through error messages and other UI prompts are essential. Documentation, specifically, is not very relevant to mobile apps because mobile apps are designed to be simple and more intuitive given its "mobile/on-the-go" nature. Documentation also take up valuable CPU space. A possible heuristic that is missing for mobile apps is optimizing battery consumption in limiting power-intensive layout changes and designing around simple interfaces.

Michael Treger 13:27, 21 September 2011 (PDT)

Eclipse/Android is the best prototype tool. It is good for both horizontal and vertical prototyping. You can quickly build the framework for you interface without implementing all the functionality, or you can choose one feature to develop further. Another benefit of prototyping with Eclipse/Android is that you are creating your app on the final device and the results from your testing will be more meaningful.

The 10 principles outlined by Nielsen are all applicable to mobile phones. One that should receive higher priority is Aesthetic and minimalist design. Given the amount of space on a mobile device, it is important that each screen does not contain too much information and that the information is large enough for people to see and interact with.

Victor Tjhia 13:31, 21 September 2011 (PDT)

I would say flash will be the best to implement T-shaped prototype because it is more graphical based then Eclipse; therefore it will be easier for users without much technical background. Since Flash provides quick and easy graphical approach to the prototyping, it should be easier to use and understand. On the other hand, flash has a limited functionality so it might not be suitable for vertical prototyping.

There doesn’t seem to be anything important that is conspicuously missing from Nielsen’s list. I think the most irrelevant from the list is “Help and Documentation” because most apps are already designed to be very simple and easy to use.

Minkai Ong 13:44, 21 September 2011 (PDT)

1)I think Flash is the best for the “T”-shaped prototypes. Flash can be used easily without worrying about the implementation. And we can use it to focus on one feature at a time. This will create the “T”-shaped prototypes.

2)The 10 heuristics on Nielsen’s list is still relevant to mobile apps. Although the 10th item, help and documentation is very rare, if any, probably due to the small amount of memory mobile phones have. So it is important for developers to make sure it is not needed. I think something that is missing is that developers have to make sure the GUI components and other displays are large enough. Mobile phones have a very small screen size and there are a lot of cases where there are too many things squeezed onto one screen. So, appropriate size and color should be chosen to increase the visibility of the system.

Calvin Hu 13:48, 21 September 2011 (PDT)

Since horizontal prototypes are about quickly transitioning between mockups of screens or panels, web forms is what I'd use to establish a feel of the system, yet not have to actually implement any of the features. But when dealing with vertical, which demands functionality, it has to be eclipse/android. You have to code, you have to do things properly. Overall, Android though does a pretty good job allowing both types of prototyping.

The Nielsen heuristics are all still applicable to mobile apps, because Nielsen had set out to create heuristics that are relevant for any design, mobile inclusive. However, we're starting to see a trend of reduced visibility of system statuses - consumers no longer care about memory used or technical data, but rather only whether the UI works adequately. A hand-wavy, removed from the user, "fix-all-that's-wrong" button is all the user really desires.

Jingchen Wu 14:02, 21 September 2011 (PDT)

My ideal combination of implementing a scenario (specific features, low functionality) would be done in a web browser in HTML or pen/paper. It's very easy to stage a scenario with images and hyperlinks, as well as rapidly prototype form tools and basic functionality, as well as modify the prototype rapidly and still have everyone on the team understand what's going on.

I would believe all of the heuristic are important to mobile applications, maybe except for the help/documentation part. Usually mobile devices have small screens and people tend to not look for documentation online. Perhaps the better way to do it is with a video tutorial link in the help section. The most important heuristics, however, would probably be system status, since mobile phones are very dependent on battery power, network status, etc., and aesthetic and minimalist design, since of the lack of screen space. Mobile users are usually in a hurry, too, so acceleration and emergency exits may be important (in case the user gets a call in the middle of the app)

Heidi Galbraith 14:05, 21 September 2011 (PDT)

There is no one tool that is best for all prototypes. For a vertical prototype, it would be prudent to experiment with what you actually plan to use in your implementation. For a horizontal prototype, Flash would be useful in order to give users a feeling for what the product will look like. That being said, it varies depending on what exactly you are building. You wouldn't want to build a prototype that is completely unrealistic based on how you will actually be implementing things.

The list of 10 heuristics seems relatively applicable to mobile applications. However, those relating to error notification and recovery seem a bit out of place in mobile application development. The requirements listed in the reading seem to be less stringent than one would hope for on a mobile device, as there is much less screen space to read error messages and help documentation. One thing to be added to the list is understanding how/when/why the mobile application is going to be used. If it is a transit arrival time application, then the user does not want to have to navigate through multiple menus in order to get the information they are looking for, whereas for a game one might expect the user to be in less of a rush.

Michael Chen 14:06, 21 September 2011 (PDT)

  • In terms of prototyping tools, (Flash vs. Eclipse/Android vs. a set of web forms browsed from an Android device) which do you think would be best for the "T"-shaped prototypes Nielsen describes?
    • I believe that more can be controlled and accomplished with Eclipse/Android. Not ever functionality needs to be built in, faux formalas and images for mockups work perfectly well too.
  • From the 10 heuristics on Nielsen's list (which are for PCs), is there anything that is not very relevant to mobile apps? Anything that is conspicuously missing?
    • These heuristics for computers are all still relevant for mobile apps. A mobile device is usually still a computer, but falls into a newer subcategory of computer where computing power and screen size is smaller. Because of that intuitive controls and windows will change.

Markus Geyer 14:11, 21 September 2011 (PDT)

If I had to pick just one, Flash would probably be the best. It seems like it could handle both the vertical and horizontal component of the prototype better than the other two. However, if we can use multiple tools I would go with web forms for the horizontal component and eclipse/android for the vertical component.

Of the 10 heuristics that Nielsen describes I would say the one that applies least to mobile platform development is: Help users recognize, diagnose, and recover from errors. It doesn’t really help to give someone an error message if they don’t have much freedom over how the platform operates. Personally I haven’t found ways to configure my phone to work around specific errors produced by some of the software.

Gautam Jain 14:16, 21 September 2011 (PDT)

I think when doing a "T" shaped prototype, using Eclipse and Android to prototype would be a cumbersome process. I feel like web forms would be the easiest way to go about prototyping, especially since prototyping works better when its rapid, easy to change, etc.

The 10 usability heuristics by Nielson are still very much relavant mobile apps. However I feel like there is one aspect that is not mentioned, and that in PC design is not that important. The primary way of interacting with mobile apps is by touch, not a mouse and keyboard that is usually used for a PC. Therefore designers need to take into account the positioning of different UI elements on the screen to make them easily accessible and controlable. I know Android developers often debate whether main controls (such as tabs, menu buttons, etc) should be consistently located at the top or bottom of the Android screen. A mouse can allow for far more dexterity and accuracy as a pointing device, whereas with a finger, accuracy becomes a lot harder.

Stacy Hsueh 14:20, 21 September 2011 (PDT)

  • One reason for choosing web forms as the main prototyping tool is its ease of use. One of the purposes of horizontal prototyping is to clarify scope and requirements. Web forms are able to achieve that end without spending too much time on the technicalities associated with flash and eclipse/android. It's also suitable to vertical prototyping despite its limited functionalities. If efficiency (rather than high-fidelity prototypes) is the primary goal of the team's prototyping process, web forms are sufficient.
  • All of the 10 heuristics are applicable to mobile apps, though less emphasis can be placed on help and documentation. Since mobile apps are less likely to require extensive documentation because of its reduced complexity. Also, documentations might use up significant chunk of the already limited storage space on mobiles. A FAQ-type section will be more helpful.

BoYan Li 14:19, 21 September 2011 (PDT)

I think all these three tools have their individual advantages. Flash is very useful when we are doing the graphical layout. Eclipse/Android based on coding and is more about the initial stage of implementation. The web form is easy to learn and design for most people. So it really depends on what the designer is good at and what the design project is about.

Also, on my opinion, almost none of these ten heuristics on Nielsons's list is not relevant to the mobile apps. They are all the basic idea about how to design the apps. However, "Recognition rather than recall" maybe the least relevant to mobile apps, since it is not very compatible to the size of mobile.

LilithSchneider 14:21, 21 September 2011 (PDT)

Since the "T" shape Nielsen describes is actually an intersection between vertical and horizontal prototyping, it is hard to pick an ideal tool for the job. Flash, for example, is best for horizontal prototyping that explores many different features, while Eclipse is mostly used for implementing features in vertical prototypes. Because it is more difficult to show full functionality with Flash, I would probably choose Eclipse and end up spending a bit of extra time on the features. There are also other Android development tools that may be useful. provides a development environment that translates javascript into mobile applications.

The 10 heuristics are all still relevant to mobile applications, surprisingly. Visibility of system status & help and documentation may need to be implemented differently for a phone than a pc, but it is still important to think about them when developing. Everything else are still extremely relevant, especially minimalist design, consistency, and user control.

David Powell 14:22, 21 September 2011 (PDT)

I believe a Flash based design would be ideal for a horizontal prototype. Flash is easy to use and has a plethora of tools to design an application with little functionality. This differs from a vertical prototype design where full functionality is expected. For full functionality I would use Eclipse to design the applications with working components.

Of the 10 heuristic I feel that they ALL apply to mobile applications. I feel that when a user is working with an application he/she expects to have many of the features and functionality outlined in the 10 heuristics.

Matthew Leung 14:24, 21 September 2011 (PDT)

I believe that the web forms are a good solution to making T-shaped prototypes. They are fast and easy to implement. Web forms are nice in that increasing either functionality or feature takes little time. Also, it is convenient that the prototype can be tested at varying levels of completeness, whereas programming will require enough work done before compilation can happen. Flash is similar to web forms, but slower and higher fidelity. Choosing between that and web forms is up to preference and experience in either one.

For the 10 heuristics, it seems that most of them are useful and applicable to mobile applications. One that I do not consider as important would be documentation and help. Mobile applications should be simple and convenient, given that one does not spend as much time on the device as compared to non-mobile devices. Things should be self-explanatory or easy enough to figure out so that users will not have to consult help or any kind of documentation. The most important ones I think would be efficiency and the minimalistic design. Mobile applications need to be quick and to the point; users should be able to get to what they need quickly without having to spend time navigating through clutter and unnecessary features.

Catherine Callaghan 14:25, 21 September 2011 (PDT)

1. In terms of prototyping tools, (Flash vs. Eclipse/Android vs. a set of web forms browsed from an Android device) which do you think would be best for the "T"-shaped prototypes Nielsen describes?

The "T"-shaped prototype requires a user interface as well as a meaningful amount of functionality, so it is best to implement it in some medium that will not require too much work to use for making a intelligible UI but that will also provide enough power to implement the necessary features. One could use something as simple as paper for this depending on the depth of functionality required. If that depth is not considerable, then the ease, flexibility, and minimal time/money cost of making a UI through drawing with pen/pencil makes paper an attractive option. If greater functionality is required, then one could use HTML/CSS to retain a high degree of ease in creating a UI and provide more features than paper prototypes can.

2. From the 10 heuristics on Nielsen's list (which are for PCs), is there anything that is not very relevant to mobile apps? Anything that is conspicuously missing?

Nielsen's list of heuristics contains many good general UI design principles, but some of them are not as applicable to mobile devices as they are to PCs. For example, "Recognition rather than recall", the idea that "[i]nstructions for use of the system should be visible or easily retrievable", is a nice property to have but not as easy to do on a mobile platform. Because of the small size of most mobile devices, there is not a lot of space to put instructions, so users have to do more figuring out of stuff on their own. Also, it is currently the state of the mobile app space that many apps are either mobile versions of software or web services that people are already used to using in a full form, so less instruction is needed for those because of users' prior knowledge. Another principle that is somewhat compromised when it comes to mobile apps is "Flexibility and efficiency of use", which states that there should be shortcuts for experts to manipulate the system faster than novices. The limited nature of inputs users have to many mobile devices makes it harder to offer a wide range of controls that can serve users of different experience levels. Without constant access to keyboard shortcuts and right-click pop-up menus, expert users cannot really have many more ways to interact with the system than the same key presses and screen taps as the novice users.

Scott Goodfriend 14:26, 21 September 2011 (PDT)

Prototyping tools. No single tool can be considered the best at creating the "T"-shaped prototypes Nielsen describes. A web form or toy payer model can cheaply model a shallow implementation of a feature. Therefore, if a complete horizontal prototype encompassing a wide range of features is desired, a paper or web form model could do this most economically. On the other hand, a vertical prototype that attempts to fully implement a specific feature would be redundant in most forms of models since an actual implementation would have to then be remade in the finalized code. Therefore, a vertical prototype with an Eclipse/Android implementation that makes features external to the vertical prototype dummies or inaccessible would be most efficient and effective. Flash exists in a middle ground between quick prototyping and fidelity, it is somewhat more difficult to add to compared to a paper or web interface and might not be as faithful to the final implementation as development environment prototype.

The major factor in choosing a prototyping tool is speed. If the developers are familiar with a specific tool, such as Flash, then Flash could be the best tool to make the "T"-shaped prototypes or the "scenario" prototypes Nielsen pushes for. Using the development environment, in our case Eclipse/Android, is not recommended because it tends to solidify developers with certain aspects of a project while other mock-ups are easier to change from since they require redevelopment to the final implantation anyway. Flash works better for graphically intensive products, while a web-form is quicker for more text-based products.

The 10 usability heuristics in Nielsen's list are still very pertinent to mobile apps. Nielsen's rules of thumb are still relevant because they are useful guidelines for making any product pleasant to use for users. Nielsen states that the need for help documentation needs to be minimized; however, there are going to be cases where it might be absolutely necessary. Mobile applications usually give contextual clues to circumvent document; however, if a user still has a question, there is nothing more frustrating than finding no documentation. One heuristic that Nielsen should add is to ensure connectivity of data and usability outside of the specific application. A modern trend in mobile apps, and products in general, is to have mobile apps work well with other products that a user would naturally use with the mobile app. For example, a word processing application should also be able to edit and save to formats that work with Microsoft Word or with Google Docs; or a blood pressure application should be able to export data to spreadsheet form. Nielsen might not have added this heuristic because it tends to be important for productivity and serious applications; however, an application that is integrated well with another product or a framework will make the user feel less like the application works in a vacuum.

In the similar vein of working well with others, a mobile application must not take up unnecessary resources in processing, time, and battery power. An application must be usable within the framework of normal daily use, and any application that causes extra inconvenience will still have to be avoided by the user.

Benjamin Hsieh 14:48, 21 September 2011 (PDT)

Flash would be ideal for the top layer of the T, while Eclipse/Android are more applicable to the body of the system. Flash is extremely useful in prototyping applications, but Eclipse/Android would be useful in actually building more defined structures.

Error recovery is often not properly handled in mobile apps - more often than not any significant errors cause the applications to crash to the home screen entirely.

Felix Wong 00:26, 24 September 2011 (PDT)

In terms of development tools, there is not one that would fit the "T"-shaped prototype. They can all fit the prototyping techniques. Flash games can be made to be quite complex, though that is generally not the case. It may be simpler for Flash games to implement different features easier than more functionality. Eclipse/Android could have more functionality since there is more you could do with the programming environment. Web-based applications are usually a combination of functionality and different features, since these applications can use a broad range of programming environments to interface with the web forms.

Visibility of system status is needed depending on the application on the mobile device. It depends on what is actually happening in the game. The same is true for recognition rather than recalling objects in the game. Some games may need the user to memorize dialogue or objects in order for them to play it. Flexibility and efficiency of use would be necessary for users, but also the ease of the use of the application. Many times, when a game causes an error, the game just crashes. There is rarely any error messages displayed to help the user. Documentation is usually not needed for games, but there are cases when the application or game to very difficult to use the first couple of times. Since the mobile application is constantly changing, these heuristics will continuously change. One thing applications could do is be integrated more with the cloud and offline usage when not on the mobile device itself. But as of now, there is not much missing from this list of ten heuristics.

Personal tools