Wednesday, December 15, 2010

On the need for anti-dogmatism: How climate change denial, wikileaks conspiracy theories, and medical dogmas are all rooted in viral memes

As a scientist, one of my deepest beliefs is that I must be open-minded to new evidence and willing to refine or even reverse my position on issues. I should be skeptical of all accepted wisdom and skeptical of the veracity of evidence in all aspects of life. The whole method of science is based on this. Society would be a lot better if our politicians and the populace at large adopted this way of thinking too.

The opposite way of thinking is being ‘dogmatic’ or closed-minded.

Unfortunately, some people who on the surface promote openness are in fact quite dogmatic. This would appear to be the case for Julian Assange, the Wikileaks founder, who appears to strongly believe in conspiracy theories regarding the US government. A very good article in the Globe and Mail explains that he holds these views despite apparent contradiction in the documents his own organization leaked. This growing evidence about Assange’s dogmatism has served to increase the negative opinion of Wikileaks that I expressed in my previous blog post. Don’t get me wrong: In future blog posts I will explain that I think there is an awful lot wrong with US government policy (and Canadian government policy too by the way). But my assessment of the evidence leads me to believe that the policy problems are caused by inherent problems in the system itself, rather than some imagined central conspiracy. However, as a good anti-dogmatist, I stand to be corrected.

There are dogmas in every field of human endeavour. Creationism and other religious fundamentalist views are clear examples. Other examples of dogmatism include right-wing views about the ‘obvious’ superiority of the private sector in all matters, or left-wing views about the ‘obvious’ need for governments to run or heavily regulate most enterprises. Hard-held convictions that harsh punishment will solve crime problems, or that poverty can be solved by government handouts, are both equally dogmatic.

Many people are dogmatic about climate change. I personally subscribe to the view that climate is indeed changing under human influence, and that this is indeed a critical issue. My position comes from reading the evidence. But I try not to be dogmatic: Reading what the other side has to say is important, as their may be grains of truth in what they say. Climate change deniers are dogmatic, but so are protesters who believe that you can accomplish meaningful change merely by protesting.

People are dogmatic about the right way to raise their children, or how to eat in a healthy way. Unfortunately these are areas where the evidence is conflicting and changing. Dogmatists tend to hold fast to a body of evidence. An anti-dogmatist such as myself must be willing to express an opinion based on a limited body of evidence, but must be equally willing change that opinion as new evidence arises.

Widely expressed medical wisdom (i.e. dogma) holds that fats in the diet are bad and that to avoid obesity, one should reduce total caloric intake. But in fact there is plenty of evidence countering that. I personally feel the evidence expressed in the book Good Calories Bad Calories is pretty convincing, so I tend to take a view that is opposed to the medical consensus (I know doctors who agree, but I am not a doctor, so please don’t take this as medical advice). I read new papers as they come out and notice that many of them include data on issues related to the medical dogma, but which don’t directly support or reject it. Nonetheless in the analysis of the results, the tendency is to repeat the dogma; an example is in this recent article.

Judy Johnson, a psychologist in Calgary, has an excellent blog on the topic of dogmatism. Her focus is the dogmatism of individuals, but it seems to me that dogmatism can be a self-reinforcing societal problem. A dogma can be a viral meme, that spreads and self-perpetuates, and can be as damaging as any other type of virus. People who are open-minded in many respects can hold dogmatic beliefs simply because there is little well-accepted evidence either way. They also might not know about counter-evidence, or don’t have the knowledge or time to assess it. Finally, they might be embedded in a society where expressing doubts can result in ostracism or worse. And I am not just talking about totalitarian regimes here; this can be a problem for small clubs, professional societies and democratic governments. People in these societies learn to be dogmatic, and learn to be offended by challenges to the dogma that they see as disparaging their society.

Even in my professional field there are dogmas: The waterfall method of software engineering dominated for many years, even though its originators didn't believe in it and many people deep down realized it did not work for large systems. Professors, government standards and books perpetuated this method until relatively recently, and some people still teach it since they are unaware of the counter-evidence. A similar viral meme in software engineering was the idea that extensive documentation is always good. The counter-evidence is that it gets out of date and that people rarely look at it. Another dogma held to this day by a minority is that formal (mathematical) methods of specification should be used for most if not all software. Discussions of particular models of software development such as model-driven development tend to provoke strong opinions both for and against.

I think that in many cases, the only way to eradicate a viral dogmatic meme is through careful and reasoned introduction by opinion leaders of stronger memes, coupled with the promotion of an evolutionary process where the best ideas of all the competing memes (perhaps including some aspects of the original dogma) can eventually emerge as the new ‘best practice’.

The meme in software engineering of ‘test-driven development’ for example is now competing with ‘formal specification’ as a good way to obtain many of the same benefits. In my Umple research I am trying to develop an approach that bridges the gap between code-driven and model-driven engineering.

In fact, this notion of ‘bridging the gap’ I think is essential to overcoming dogmas. Most climate change dissenters for example use economic dogmas (e.g. that economic growth is overwhelmingly important) to help rationalize their position. Perhaps the pro-economy and climate-crisis positions can be bridged by promoting a ‘growth of human well-being’ perspective. This would recognize that economics and climate are both drivers of long-term well-being. The same approach should be used by people trying to overcome other dogmas widely held in their society.

I will have more to say about specific dogmas (political, economic and technical) in future posts.

Thursday, December 9, 2010

Four iOS mapping applications

I regularly use four different iOS mapping applications. They all have their advantages.

Google Maps, the built-in app, is excellent. The integration with transit schedules in many cities is awesome. It’s main weakness is that it requires a data connection, so I use it very little in foreign countries where data costs are exorbitant. I would like to see the option for ‘+’ and ‘-‘ buttons to zoom in and out: The pinch gesture is awkward to use with just one hand, such as when holding something in the other hand, or riding a bike. I would also like the option to display alternative routes, just like in the Google maps website.

MotionX GPS is my main mapping application when I switch data off, or when I want to track my path or a set of waypoints. One can pre-load maps, at different resolutions, for places one intends to visit. It has a whole host of other features that also prove useful from time to time. Its most annoying issue is the splash screen that appears on startup. Its second-most-annoying issue is that when you select a waypoint and ask to show the map for that waypoint, you cannot keep the map at that waypoint. You are in a mode where you have to select 'done', after which the map jumps back to where it was. I have also found the detail in maps to be weak in some rural areas. It does have the ‘+’ and ‘-‘ buttons for zooming that I find very useful for one-handed operation. Hint: Learn what the 'zoom level' numbers mean; these appear at the bottom-right of the map. Knowing these numbers, and the amount of detail corresponding to each, will help you when pre-loading maps.

Topo Maps is excellent for detail when hiking in rural areas. As with MotionX GPS, one can pre-download the maps of the areas one intends to visit. It currently covers only North America though, and it is of little use in urban areas since there are no street names and the maps are older government-issue official maps.

Finally, I recommend Speed. This shows a speedometer at the top and a small always-centered version of Google maps at the bottom. This can be useful to see how fast you are traveling on a boat, train or bicycle. It could be improved by showing the current time and the path one has just followed (perhaps with different colours for different speeds on one’s path). An ability to display only km/h on the dial, would be appreciated.

Sunday, December 5, 2010

The Oil Drum: A website about the science, economics, sociology and politics of energy and the environment

I have broad scientific interests beyond my profession as a computer scientist and software engineer. One of them is ensuring our descendants have a sustainable environment in which to live, and sufficient energy to continue with a reasonable style of life.

All the computer technology we develop will be for naught if society descends into conflict amid shortage of resources, dwindling food supplies, and a lack of energy to manufacture or power that technology.

One of the best resources I have found on the Internet to keep up with some of these issues is the web site The Oil Drum. This covers all aspects of energy, not just oil. It also covers broader environmental and sustainability issues. What I like about the articles is that they cover the basic science, the economic arguments, the social issues, and the relevant geopolitics.

This weekend The Oil Drum has published a superb list of their best posts from the last five years. I wish all world political leaders would make it their December resolution to read these posts.

Saturday, December 4, 2010

What do I think of Wikileaks?

I am cited today in the Montreal Gazette and Global News in an article where I helped provide the journalist with a simplified view of what the public should know about Wikileaks. My comments appear at the start and end of the articles.

However, what do I think about Wikileaks itself and its recent actions in releasing the diplomatic cables?

Overall I am very much in favor of press freedom. I think responsible journalists should be able to ethically release leaked material, where in the professional judgment of themselves and their editor the public interest would served, and where there would be more benefit than harm.

In this context, serving the public interest would mostly mean revealing wrongdoing. Harms can include damaging the ability of people to speak freely in future for fear of reprisal, compromising negotiations, fueling resentment, or putting people in jeopardy. In the Wikileaks case, the harms of dumping all the cables stand to be very substantial, and we haven't yet seen evidence of systematic wrongdoing being revealed. In any open society, there remains a need for people to communicate confidentially for many very good reasons.

The key is that professional judgment must be employed. If Wikileaks took the time to read through all the cables and discovered patterns of wrongdoing, and then, carefully ensured they released only specific documents that expose this wrongdoing while avoiding consequent net harms, then one could argue that they would be behaving responsibly.

Their current approach is not, in my opinion responsible. It is over-zealous and reckless. Where will it stop? If somebody leaked to them a large number of government employee personnel and medical files, for example, would they just as zealously release them? Where are they going to draw the line? It will be impossible to stop employees from leaking confidential data (e.g. using cell phone cameras, memory sticks, etc.), so the onus has to be on journalists or quasi-journalistic organizations like Wikileaks to behave with professional responsibility.

All professions have ethical standards. Many of these involve a duty to respect confidentiality. I will have no respect for Wikileaks until they adopt much more well-thought-out ethical practices.

An article I like that expresses much the same opinion appeared recently in the Globe and Mail. It's title is Wikileaks is Gossip not Whistleblowing.

Getting rid of modal dialogs from iPhone Calendar app

The iPhone Calendar app is nice in many respects, but Apple could make it much better. In particular, it should be possible to get rid of almost all the modal dialogs which require pressing 'done' when finished.

Right now in Calendar it takes far too long, in my opinion,  to create a new event. I often have to fumble frustratingly to set all the fields I need when standing in front of somebody, e.g. at a dentist's office.

Here are my specific suggestions:

When displaying the calendar of a day, as shown below, you currently have to tap '+' to create a new event. However iOS should allow you to press and hold blank space to make a new event appear, in edit mode. This would make it much easier when scheduling events. The position of the finger would  indicate the time of the event. Currently the default start time for new events is the next hour from the current time, regardless of the day. For example if it is 1:24 on Dec 1, and I am scheduling an event for Dec 2, the new event will default to 2 p.m. until I later adjust it. This is rarely useful.

When you click on an event you get an 'Event Details' screen as shown below. If you want to edit the event, you have to press 'Edit'. iOS should allow you to touch any field to immediately jump into editing of that field. You might argue that this would result in accidental editing, but accidental changes should always be reversible by shaking.

In editing mode you have to click on a field, edit the field, then tap 'Done'. You have to follow this process for every field. Instead, iOS should allow editing calendar fields directly, and move on to editing other fields without any need to tap 'Done'. For example, if I am in the middle of editing the title of an event, as shown below, I should be able to 'flick' down to see another field such as 'alert'. The title would be saved, the keyboard would disappear, and the control for alerts would appear. No more pressing 'done' for every field.

When editing 'Starts' and 'Ends' to set an event's time, one is presented with the 'flick wheels' interface, shown below, which can be quite nice in other contexts. However I think here a major improvement is possible. It would be better to see the context of the event, in other words a mini schedule for the hours surrounding the current time that would allow the user to drag the entire event, or just the start and end of it, so as to position it among other events on that day more easily. There would be space for this if the interface for picking the day just showed the chosen day and date, with 'next' and 'previous' arrows next to it.

In 'Calendar' editing mode, shown below, you put a check mark next to a calendar. As soon as you pick the calendar, the interaction should be done. There should be no need to  force you to tap 'done'.

Implementing all the above recommendations would very considerably reduce the number of gestures required to add or modify an event.

Friday, December 3, 2010

Usability Blooper: Alarms that go off just before midnight

I have been woken up out of a deep sleep far too many times by alarms that go off before midnight due to this blooper.

One of the options on iCal on Mac OS X is to specify that you want to 'Add a default alarm to all new events and invitations'. This is shown at the bottom of the preferences dialog below:

This can be extremely useful. For years when I owned a Palm OS device I would have new events default to sounding an alarm 15 minutes in advance. That way, I wouldn't forget an event because I was in too much of a hurry when entering it. Entering events is also faster this way.

Unfortunately this default applies to 'all-day' events, and iOS devices dutifully obey this command and hence sound a alarm just before midnight. When adding an all-day event in iCal you have to remember to turn off the default alarm. The following is the screen where you have to do this:

It is all too easy to forget about the alarm that is being automatically set. The same applies when converting a regular event to an all-day event, or loading events from other calendar programs.

This could be a safety issue: Features that can contribute to people being tired the next day could cause significant harm.

Here are the required changes: Firstly, iCal preferences should include another box below  'add a default ...'  that allows you to indicate 'except for all day events'. In addition, iOS should have an option 'Do not sound alarms just prior to midnight for all-day events the next day'. This would allow alarms for certain numbers of hours prior to midnight to sound, but not alarms for these events specified in terms of minutes before midnight.

After I converted to iOS I was awakened many times, since my previous Palm Treo behaved the way I wanted in this regard. I had to go through all my recurring all-day events, which included birthdays, holidays, annual maintenance reminders etc. to get rid of these pesky pre-midnight wakeups. I expect thousands of other people have been inflicted with the same problem. And now, there is no way I dare use the default alarm option, which is a shame.

Thursday, December 2, 2010

Three gestures I'd like to see added to iOS

Here are three suggestions for easy-to-use and extremely useful gestures that I think Apple should add to iOS with absolutely no effect on existing usage patterns:

1. Swipe up in any home screen. Currently this does nothing. What a wasted opportunity.

My suggestion for this gesture: Invoke a pre-configured action. This would allow quick access to an important app or web page of your choice, and in particular it would allow access to these without looking at the screen, a major benefit if you are driving, in a meeting. etc. This gesture should work whether you are in an 'ordinary' home screen, a 'folder' screen, the 'search'  screen, the 'recent apps' screen, or the 'voice control' screen. That way, any use of the home key followed by an up-swipe would invoke the chosen action. Actions invoked would be specified in the preferences panel; perhaps the default could be 'phone' or 'camera'. This would be an alternative to my earlier suggestion for dedicated hardware buttons.

2. Swipe down in any home screen. Same as above. Note that currently in the 'search' screen, this gesture hides the keyboard, which is rarely useful in that context.

3. Press the 'home' key and tap anywhere. Currently this behaves in a way that is not useful: As you press down on the home key, nothing happens; as you then tap anywhere, the normal tap action happen but inevitably this will momentarily have to be forgotten as it is essential for you to release the home key: as you release the home key, the home page is displayed. Or, if you hang onto the home key, Voice Control is dsplayed.

My suggestion for this gesture: Universal 'get information'. This would work as followed. Almost instantly after pressing, but not releasing the home key, all tappable areas of the screen would be graphically highlighted. Tapping one of these while continuing to hold the home key would yield whatever the app desires in terms of general information. This could be help about how to use gestures on the area, statistics, etc. iOS apps should not need much help, but many apps have a non-discoverability problem, This gesture would help overcome that. If you used this gesture in a home screen, for example, this could tell you whether the app was running in the background, give you access to settings, tell you how many times you have run the app and when it was last invoked, point you to the app's web page or iTunes page, and allow you to recommend the app to others or write a review.

Saturday, November 27, 2010

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.

Friday, November 26, 2010

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.

Wednesday, November 24, 2010

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;
8     public String fullName()
9     {
10       return getFirstName() + " " + getLastName();
11    }
12 }
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()

Monday, November 22, 2010

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.

Friday, November 19, 2010

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 . 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.

Thursday, November 18, 2010

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

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

Wednesday, November 17, 2010

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.