Usability Blooper: iCal inescapable dialog - You’re about to send an invitation

 From time to time I will post samples of usability defects I find particularly egregious.

Today’s blooper occurs in the Mac calendar program iCal (version 4.0.4 (1395). It occurs when you invite people to a meeting. When you try to close the event editing dialog, the modal dialog below occurs, saying “You’re about to send an invitation for [the event]. Do you want to send [the event] now or continue editing the event?”

The problem is that there is no obvious way to ‘escape’. You have to send to proceed. If you click ‘edit’ you are just taken to the dialog behind where you are editing the event. You can’t close that dialog; if you try to, the “You’re about to …” modal dialog reappears. You can’t quit iCal either without the dialog reappearing. And if you ‘force quit’ iCal, the pesky dialog reappears as soon as iCal starts again!

This might not on the surface appear to be so bad. After all, if you have listed some people to invite, presumably you want to actually invite them. The problem is, this dialog often appears ‘accidentally’. If you touch the event in the daily layout, perhaps dragging it a little by mistake, it thinks it is a ‘revised event’ and all the participants must be informed (although it still asks to 'send an invitation' rather than 'send invitees notice of a change'). If you want to put some comments on the event for you own information, it insists on having you send this to everybody invited.

I have often wanted set up an event in my calendar yet not immediately send the invitations until I am ready to do so. No can do. Invitations must be sent or you are in dialog hell.

There is a workaround: Delete all the invitees. But then you have lost track of everybody you were planning to invite (or everybody you did invite if this is a minor update you don't want to bother telling people about).

Apple needs to fix iCal so you can save a changed event without sending it to the invitees. It could put a graphic flag on the event  warning you that you have not completed sending invitations or updates.

Hardware buttons on mobile devices: Which ones should be standard?

Android phones generally have at least volume-rocker, home, back,  search and power buttons. Windows Phone 7 devices must have these plus a camera button (but home is called 'start'), with strict rules that software cannot override the basic function of these buttons.

iOS devices, have a nice 'mute' switch, but lack the hardware 'back', 'search' and 'camera' buttons. I think a strong argument should be made to add at least one, if not two additional hardware buttons to improve user experience.

Two situations I think justify a hardware button:

1. An action that should be common to all apps. 'Go back' qualifies under this criteria. This ought to go back to the previous 'flagged' state of the current app (e.g. a previous web page), or to the previous app if there has been no flagged state since arriving at this app. Smooth transition forward and back among apps would be much easier. The 'go back' should be unlimited, to the greatest extent possible, so you could go back to where you were 5 or 6 actions ago.
2. An action that may need to be performed urgently, or with gloved hands, ideally without looking at the screen too much. Taking a picture, displaying one's current location on a map and phoning a key number from one's list of favourites qualify for this, in my opinion. 

If you apply both the above criteria, it would suggest four additional hardware buttons (back, phone, camera and map) in iOS. This is likely too much for Apple to ever agree too. Perhaps, they could be pursuaded to add two though:

The back button to the left of the home key. One click to go back. Hold it to go to the map app in 'current location' mode for reduced cognitive load when driving.  Perhaps your choice of navigation apps could be substituted. I personally like MotionX GPS when roaming because it allows you to cache maps.

The quick app button to the right of the home key. The default would be one click to bring you to the camera app, and if you are already in that app, to take a picture. No more need to take gloves off or fumble when a photo op arises. Hold the quick app button to instead bring up the phone app. If you are already in the phone app, it would phone the first item in your contacts. You can now initiate a call home with your phone in your pocket, using your bluetooth device. Or if you wanted you could program this as 9-1-1, so you could call for help unobtrusively. It also ought to be possible to override the defaults to allow you to make other apps your 'quick access' ones.

On iPhones the user always can place whichever apps or web pages they want on their home screen. This is great for most purposes, but not for the two situations I outlined.

I don't think a 'search' key is really justified as a hardware feature. Many apps have no need for search functionality. And global search can be accessed using the home key and a swipe. Although it's unfortunate that not all apps display listings on the global search. Usually if you are going to search, you have to type, so this is not a hands-free type of operation that would justify a hardware button.

I can imagine that when doing an outdoor activity,  I might want to rapidly alternate between map, camera and answering or initiating a call. When driving I might need to alternate between navigation and phone without taking my eyes off the road (assuming that the navigation app speaks out directions). The number of times I have been taken from app to app and then to a web page, without a very quick way to go back, also makes me crave a back button.

Stephen Tenerowicz has his own thoughts on hardware buttons. Design guidelines for Android can be found here. iOS human interface guidelines are here. Windows Phone 7 human interface guidelines are here.

Umple tutorial 1: Basic attributes and associations

From time to time, my posts will include short tutorials about how to use aspects of Umple. This is the first such tutorial. For an overview of Umple, see my recent post on this blog, my recent post on Jordi Cabot's blog, or go to the Umple home page.

In the  Umple below:

• Lines 3, 4 and 5: These define Umple/UML attributes, not Java (or PHP or Ruby) member/instance variables. Since they are attributes, the generated system will have private variables, get methods and set methods for each. In a later post, I will discuss other keywords you can use with attributes, e.g. to make them immutable. I will also show how to inject different code into the generated functions, so there is never any need to edit generated code itself.
• Lines 3 and 4: These show how Umple defaults to using String as the data type for attributes. The reason we did this is to allow for quick modeling with little need to initially worry about the type of an attribute. Sensible code can still be generated.
• Line 5: Integer is an Umple data type. When generating Java, Umple will use the type int. However, Umple can also generate PHP and Ruby, which use dynamic typing.
• Line 6: This shows a many-to-many association with the class Address. This association is bidirectional meaning that if you have an Address, you can find all the Students who live there . Several students can share an address, and a student may have several addresses on file. A student must have at least one address. Umple supports all possible UML multiplicities, and maintains referential integrity if associations are bidirectional, like this one is.
• Lines 8 to 11: These constitute a normal Java method. This is not further processed by Umple; when you generate a system, these lines are passed through unchanged. Without these four lines, the code would be ‘pure model’, and code could be generated from the file in Java, Ruby and PHP. But with these lines, the developer has committed to using Java as the base language. It it possible instead to keep all base language code in separate file(s), therefore separating pure model from base language methods. You could even have separate files for Java methods and equivalent PHP and Ruby methods. This would allow you to generate equivalent final systems in all three base languages.
• Line 16: This shows that attributes can be many-valued.

1  class Student

2  {

3     firstName;

4     lastName;

5     Integer number;

6     * -- 1..* Address;

7 

8     public String fullName()

9     {

10       return getFirstName() + " " + getLastName();

11    }

12 }

13

14 class Address

15 {

16    String[] line;

17 }

Copy and paste the above into UmpleOnline and generate Java code to see what happens. Or put it into a file StudentAndAddress.ump, and compile it on the command line or in Eclipse.

How would you use such a file in your development? Most likely, you would create methods in various Java classes that use the generated Java API shown below. Some of your methods could be injected into classes Address and Student, using Umple’s mixin mechanism.

Constructor of Student

  public Student(String aFirstName, String aLastName, int aNumber, Address... allAddresses)

Methods of class Student

  public boolean setFirstName(String aFirstName)

  public boolean setLastName(String aLastName)

 

  public boolean setNumber(int aNumber)

  public int getNumber()

  public String getFirstName()

  public String getLastName()

  public Address getAddress(int index)

  public List<Address> getAddresses()

  public int numberOfAddresses()

  public boolean hasAddresses()

  public int indexOfAddress(Address aAddress)

  public boolean isNumberOfAddressesValid()

  public static int minimumNumberOfAddresses()

  public boolean addAddress(Address aAddress)

  public boolean removeAddress(Address aAddress)

  public boolean setAddresses(Address... newAddresses)

  public void delete()

  public String fullName()

Consructor of Address

  public Address()

Methods of class Address

  public boolean addLine(String aLine)

  public boolean removeLine(String aLine)

  public String getLine(int index)

  public String[] getLine()

  public int numberOfLine()

  public boolean hasLine()

  public int indexOfLine(String aLine)

  public Student getStudent(int index)

  public List<Student> getStudents()

  public int numberOfStudents()

  public boolean hasStudents()

  public int indexOfStudent(Student aStudent)

  public static int minimumNumberOfStudents()

  public boolean addStudent(Student aStudent)

  public boolean removeStudent(Student aStudent)

  public void delete()

The ruination of the BBC website: Category-clutter and unidentified auto-play RSS video

The BBC has an enviable reputation for quality journalism, and this extended for many years into its news website.

However, in its current state the BBC site has fallen into a state of mediocrity has also befallen sites such as CNN and the Globe and Mail. I single out the BBC because it used to be, in my opinion, simply the best source for international online news. Its journalism is still good, but site-usability has fallen dramatically. It seems that the BBC has aspired to be more like other less usable websites, like CNN, rather than continuing to lead the way in terms of usability.

I have two main complaints:

Category-clutter on the home page: For years, at the top of the BBC home page one could read a limited selection of capsule news items, nicely categorized, These had informative headlines followed by a sentence that filled in useful detail.  One followed links to other thematic pages if one wanted other types of news.

Now, one has to parse a mish-mash of at least nine types of stories to find material of interest: 1) The 'Latest' constantly changing bar at the top, 2) The main story and its sub-stories; 3) Several second-level stories, some of which have substories, 3) A list of short headings without any capsule text; 4) A series of 'also in the news' headings; 5) A series of articles under 'World News' or 'UK News' tabs; 6) Series of articles under theme headings such as 'Business', 'Technology'; 7) A series of 'Special Reports', 8) A series of 'Features and Analysis' items on the right; 9) The 'Most Popular' list.  All of this also has to compete for attention with ads and other non-news links.

I would issue a challenge to news websites to dramatically simplify the number of types of articles: Perhaps it could all boil down to: a) Top stories with substories; b) Short lists of articles under theme headings; and c) The most popular list.

Some people might ask why I am complaining. Surely, they would say, why cannot I use an RSS reader like Google Reader or NetNewsWire if I want to avoid a messy home page? I would be able to, were it not for my second complaint:

Unidentified auto-play video in RSS feeds: This has become the bane of RSS reading. The BBC and other sites present headlines of most-recently-updated articles to which RSS readers subscribe. The trouble is, the RSS headlines do not indicate which items contain video, and which simply show text when selected. Worse yet, the BBC has unwisely followed the lead of other sites and has made their videos 'auto-play', meaning the video starts instantly (with a commercial these days).

The way many people use an RSS reader is to select a series of headlines and have them open in separate browser tabs ready for later reading. The trouble is, one now gets two or three videos all starting at once (playing the same commercial incidentally). This can cause embarrassment if one has left one's volume up in a public place, and can cause sudden unexpected network slowdown. In effect, it has rendered the use of RSS feeds, like that of the BBC, increasingly unusable.

Two changes are imperative:

First, video on websites should absolutely never be auto-play. There should always be a 'play' button to start it, so when a user arrives there via a any kind of link they can choose to adjust their volume and whether or not to consume bandwidth.

Second,  all RSS feed items that lead to multimedia should say so: A tag 'Video' or 'Audio' should appear prominently in RSS headline.

I will have more to say on ways to improve RSS publishing and readers in later blog posts.

Model-oriented programming (MOP) and the Umple language

My own current research focuses on a concept I call model-oriented programming (MOP), and a technology called Umple for developing software using the MOP approach. I think that adoption of MOP could lead to considerable improvement in software engineering productivity and quality.

Model-oriented programming encompasses the following:

• Adding new abstractions to programming languages: Modeling concepts, taken from UML and perhaps other modeling languages, are added, in as seamless a manner as possible, to extend object-oriented programming languages. These modeling concepts raise the level of abstraction. Example modeling concepts include UML associations and state machines.
• Choice of workflow when adopting the new abstractions: To develop software using a MOP language, a programmer can take a model-first approach or can incrementally re-engineer an existing program to add modeling concepts. The model-first approach means that you write a program in a MOP language using just the modeling abstractions initially, adding other parts of the program, such as algorithmic methods, later. The incremental re-engineering approach means taking an existing program and iteratively 1) identifying code that represents a modeling concept, and 2) replacing that code with equivalent model code. This in general reduces code volume while increasing abstraction, and hopefully increasing understandability.
• Enabling of text-diagram duality: A MOP program is inherently in a human-readable textual form, like any of the other programming languages we are familiar with, but since it also contains modeling abstractions, the code can be directly viewed as a  diagram. Furthermore, with appropriate tool support, MOP code can be edited equally well using a textual editor or a diagram editor. Changes to the diagram should appear as you edit the text, and vice-versa.
• Continuing the trend in evolution of programming languages: In MOP a model is a program and a program is a model. There is no distinction. Within the model/program there are elements of higher and lower abstraction. But this has always been the case in programming languages. Classes are a higher-level abstraction added to procedural programming languages to create object-oriented programming languages. MOP just continues this trend by adding additional modeling concepts.
• Elimination of 'round-tripping': A compiler for an MOP language acts just like a compiler for any other language. Programmers don't need to look at or edit the generated code.

With MOP, barriers to adoption of modeling should be eliminated. A programmer can use just enough MOP to get a taste for it and gain confidence before plunging into the modeling world.

My research group has spent the last few years exploring MOP and creating the Umple technology. Umple adds UML concepts such as associations and state machines to Java, Ruby and PHP. In future, we plan to also tackle C++. We call the process of reverse engineering from any of these to Umple, umplification.

Umple is a triple play on words. It can mean UML programming language, or it can mean a language with ample capability for creating programs with UML concepts. It doesn't incorporate all UML concepts, in order to keep it ultimately simple.

To demonstrate that Umple works, we rewrote the Umple compiler in Umple, hence 'eating our own dogfood'. I wonder how many modeling tool developers have used modeling to help design their own tool, let alone have generated their own tool entirely from their model.

Several professors have used Umple in the classroom, and it seems to be a useful tool to help students really understand the benefits of modeling. It has also been used in some industrial projects and student projects in several countries.

Umple is not the only language that has the MOP characteristics. The OMG's Alf language also has most of the capabilities of the MOP vision. The only exception, I think, is that instead of building UML abstractions on top of existing languages, the Alf developers are creating their own language from scratch. The ability to incrementally re-engineer will therefore be much diminished.

We plan to make Umple open source using Google Code by the end of 2010, but it is available today in two forms. You can try the UmpleOnline tool at http://cruise.site.uottawa.ca/umpleonline/ . This allows you to create Umple programs consisting of a single file both textually and graphically. There are also many examples of Umple to browse. If you want to do more serious development, then download the Eclipse plug-in; there is a link to this on the UmpleOnline page.

I will have a lot more to say about Umple in future posts. I will use the label 'Umple' so you can separate the Umple posts from posts on unrelated topics.

Credit for help with development of Umple and MOP concepts needs to go to many sources. These include IBM which have been our big sponsor, and have said they will continue to sponsor us. NSERC, the Canadian government funding agency, has also supported the work. Credit also goes to the graduate and undergraduate students who have worked, and are continuing to work on Umple. These include Andrew Forward, Dusan Brestovansky, Julian Solano, Jenya Levin, Omar Badreddin and Julie Filion.  Completed theses about Umple can be found here.

Reading text on iOS: Instapaper tilt scrolling wins

I am doing more and more reading on my iPhone these days. Here's my quick ratings of usability of several techniques deployed in widely used applications.

My eyes get tired and when the do, I need reading glasses for small fonts. I am therefore looking for a reading control in which I can adjust the fonts to a large enough size to read text quickly and easily. The 3GS I use has a screen resolution that is great for its crisp text even at small font size - as long as I can focus my eyes on it without tiring them. The 4G's retina display makes text even crisper, but this doesn't help if one has trouble focusing.

Safari and apps that simply open a web page view: Grade B-. You always have to zoom in, and in general you have to pan the screen a lot to see the left and right parts of the text. Not pleasant, but far, far better than the 'old days' before full-powered web browsers were available.

iBooks: Grade B+. You can make the font look like you want, and flipping pages is relatively easy. But you still have to flip those pages, which can be irritating as your finger has to move a lot, and it gets in the way of the text a little.

The Globe and Mail app (powered by Spreed): Basic text mode reading: Grade B+. Much nicer than reading the Globe and Mail in Safari. You can't use gestures to increase font size, but default sizes are quite readable. You flick to scroll down like a web browser. Spreed mode: Grade C. This is highly touted as a way to read faster. Groups of grammatically-related words are flashed in front of you at the speed you wish to have them appear (from 260 to 1000 wpm). The instructions say that you will get faster at reading with time, and that you should not care about the odd word you miss. The trouble is that in my experience the odd word is critical. I read one article, missing a key 'not' because I didn't have time to 'take it in' before it disappeared. I therefore ended up understanding the opposite from what the article actually said.

Instapaper's tilt scrolling: Grade A. This wins hands down. I look forward to the day when all mobile devices use it natively. As you start reading each article, you press a little icon at the bottom and then tilt the screen back a tiny bit to make the text scroll slowly. The slightest movement of your hand can speed up or slow down the scrolling, meaning that the text you are reading can always be kept in the centre of the screen. I can still suggest some improvements: As an option, it would be nice to be able to start the scrolling with a very small gesture (a shake or a large tilt). And perhaps other kinds of gestures could be used to navigate from article to article, including archiving the ones you have read. I think it would also be nice to have greater control of how the amount of tilt maps to the amount of scrolling speed, just like in 'mouse speed' preference panels found in operating systems.

I am not the first to praise this technique: See also http://thehomescreen.blogspot.com/2009/04/tilt-scrolling-for-win.html.

Maybe if tilt scrolling became the norm, Jakob Nielsen may consider updating his ratings of reading speeds for touch screen devices.

Welcome and a little background

This is my first post in this new blog, but I have actually entered a variety of blog-like posts on my home page over the years. I just thought it was time to formalize it, and make blogging a little easier. I intend to incorporate those posts into this blog in due time.

What am I likely to talk about on this blog?

I will highlight software or technology that I find hard to use, and make suggestions to improve it.

I will highlight what I believe to be misconceptions among our politicians and the public about issues such as the environment, science in general and the political system. I will also propose some ideas I have for the way forward.