Kichwa Coders speaking at Eclipsecon France

EclipseCon France 2014

The Kichwa Coders team is in sunny Toulouse this week for Eclipsecon France.  This year’s conference features an ‘unconference‘ beforehand, where we’ll be meeting with other members of the science working group.

At the conference itself, there will be a host of talks on tools in action, eclipse in the industry, IoT and lots of other cool Eclipse related stuff.  Tracy Miranda will be delivering two speeches, the first on Wednesday on ‘Lean Design Critique’ and on Thursday the boards will be coming out as Tracy does a demo and talk on ‘Espruino, Javascript for Things‘.

So come join us and say hi if you’re there.

Dawn Developer Workshop, June 2014

IMG_20140605_140625
Staring down the barrel of the beamline – good thing it was off that day

This year, the 2-day DAWN developer workshop had an added dimension as the first day was an Eclipse Science day. It was well-timed and coincided with the formal creation of the Eclipse science working group which is growing a community around Eclipse and scientific software development.  Diamond Light Source played host and the day included a fascinating tour of the guts of the synchrotron (once we made sure it really was turned off). I won’t be able to do it justice with words but here’s some great information on how it works and I’d highly recommend a visit to see it for yourself.

In the spirit of fostering collaboration, the science day featured sessions focussed around idea and technology exchange. This included demos of science tools all underpinned by the Eclipse framework: Continue reading “Dawn Developer Workshop, June 2014”

Lean Design Critique: Function Fitting Tool

The DAWN Science function fitting tool was at that stage where all the functionality was in place but it needed some attention from a usability point of view. To drive the user design forward it was run through a lean design critique  – a quick way of running a design critique to get the most worthwhile  optimizations in a short space of time.The lean design critique is described below.

The original function fitting tool

1. Meet the requirements:

The most critical requirement is to have someone who understands who the different types of users are, what they use the tool for and how they use it. The design will be largely based on that information supplied so needs to be as accurate as possible. Then you need someone to apply some design principles. To keep it lean, ideally this will be 2, max 3 people (If it was just 1 person it would just happen, no need to formalise at all).

2. Identify the 90% task

This is the job or set of jobs that will be carried out again and again (so 90% of the time) in this user interface. In this case, while it seems easy to say that that task is ‘function fitting’, it is important to go further and break that down to the key steps. As important is to identify the tasks that are infrequent, in this case things like importing and exporting of fit date to files is done occasionally. A good question to ask for each UI element is ‘How often is that used?‘ – in this case it highlighted that while users can change the accuracy of the fitting routine, in practice they rarely do.

3. Do a Cognitive Walkthrough

In this step we breakdown the 90% task to its constituent steps and perform the tasks as a user would. Because we are keeping it lean we focus on the main steps and disregard the occasionally done steps (for example deleting or duplicating a function).

In this case a typical user scenario involves the following:

  1. Click ‘Auto ReFit’
  2. Select the desired function e.g. gaussian
  3. Set the parameters accordingly (mostly value)
  4. Look at plot to determine by eye if fit looks close enough
  5. If not, tweak parameters until fit is good
  6. When fit looks good, click update all to accept fit data
  7. Repeat tweaking until happy with fit, also measured by the goodness of fit value

This is the key step and worth taking the time to get as accurate data as possible.

4. Analyse Eye Travel, Mouse Travel & Clicks

Using the steps identified, apply these to the UI with a big red marker to get an idea of the path the user has to follow with their eye or mouse. You can also count clicks to see how many it takes to perform different tasks.
Analysing mouse travel to perform 90% task
Carrying out this step for this tool quickly highlighted the following areas:
– Step 5, repeatedly tweaking the parameters requires to and fro movement between two tables. It also highlights the same data (parameters) shown in two different tables which may not be obvious to the user that one is for editing and one for just viewing.
– Step 2 – an early step for the task is all the way down and in the middle of the UI – a non-obvious place for a user, particularly a new one to intuit what to do next.
– Step 6 – a key step is hidden in a toolbar alongside other anonymous buttons

In this case, mouse clicks were not used as a significant measure, particularly due to the iterative nature of tweaking the parameters.

5. Analyse Screen Space Usage

The principle here is that UI elements should be somewhat proportional to their importance such that they draw attention to themselves. So anything used for the 90% task needs to be big and obvious, while less important tasks should occupy less of ‘prime real estate’ screen space.

Running through this on the UI highlights to key areas that are prominent and well positioned but very infrequently used.

Optimizing screen real estate

6. Explore Existing Designs

Before you optimize, a useful thing to do is a field survey/research of existing UI designs that follow similar paradigms. A proven design which already has a lot of users can often be a good starting point.

In this case, inspiration was drawn from the Eclipse expressions view. It features a table with hierarchy (treeviewer) that allows adding and editing of items in the same place – ideal to replace the duplicate tables of the function fitting tool. It also has a nice obvious way of adding new elements to the table and a sash window to a text form for additional information.

Eclipse expressions view

7. Optimize

Based on the analysis feedback combined with UI research you can then go ahead and optimize the design to suit. In this step it is useful to use a usability heuristic checklist to cover common usability areas.
Here is the optimized design for the function fitting tool:
New design for function fitting tool

Efficiency of use – the two tables are combined into one table with hierarchy to allow creating and editing of functions all in one place.

Aesthetic and minimalist design – the non-essential UI elements are removed and put in preference pages accessed by the toolbar menu. This reduces the clutter and keeps the user focused on the main tasks at hand.

Visibility of system status – the value for normalised goodness of fit is given a more prominent position. Also the previously obscured update button is given more prominence and screen real estate.

8. Rerun Analysis

For good measure we run the analysis steps on the new design to ensure it fits the bill.
Analyse mouse travel

9. Conclusion

Further analysis and optimization can of course be done to ensure other tasks are not too overbearing for the user, but when design time is limited, doing a lean design critique is most efficient for a good working design optimized for the main user task.

Function Fitting Tool:Before & After

Continue reading “Lean Design Critique: Function Fitting Tool”

Using Eclipse Common Navigator Framework for the NeXus Navigator

Requirement:

The Eclipse common navigator framework (CNF) is used as the basis for the NeXus Navigator within the DAWN Science platform. The nexus navigator provides a focussed view on nexus files, but in doing so removes the directory and project structure. However, more typically users need to focus on their nexus files within the context of their directory structure (often very deliberately set up and related to the experiment).

Pre-existing navigator with flat directory structure flat
Pre-existing navigator with flat directory structure flat

So the requirement is to show the existing directory (and project) structure but provide a filter such that only Nexus files are shown.

Solution:

Based on this requirement  and the existing codebase, the actual work requires more deprecating code than writing it.
There was a specific content provider class written to flatten the structure. This and the corresponding label provider are no longer required: displaying files in the view is delegated to the default Eclipse resource content and label provider. That way the files always appear the same in any navigator view.
solution-image-1

A filter is required, and the common navigator framework provides powerful extension point that allows it be implemented completely statically using xml. The filter automatically shows up in the view customizations but could be hidden if needed.
solution-image-1

Rabbit holes:

Based on past experience, using expressions in Eclipse plug-in extension points can be tricky – if they don’t work, it’s not straightforward to debug why. Usually referencing the documentation coupled with a working example is a good starting point. Here’s the filter expression for this case (which came with a certain amount of trial and error):

<filterExpression>
 <and>
  <not>
   <adapt type="org.eclipse.core.resources.IFile">
    <test
      property="org.eclipse.core.resources.extension"
      value="nxs">
    </test>
   </adapt>
  </not>
  <adapt
     type="org.eclipse.core.resources.IFile">
  </adapt>
 </and>
</filterExpression>

In particular, note it is best to use the tag rather than to ensure the filter works not just for files but anything masquerading (or adapting) to the IFile interface.

 

Testing:

There is no Java code provided that requires unit tests. Using the extension point takes advantage of the pre-existing testing and repeated use by the open source community. The expression can be verified and so tests for the navigator are naturally rolled into tests for upcoming features intended for the navigator.

 Resources:

  1. Common navigator framework – http://wiki.eclipse.org/index.php/Common_Navigator_Framework (the blog resources are particularly useful)
  2. Eclipse expressions reference – http://wiki.eclipse.org/Command_Core_Expressions

P2 Update Site for the DAWN project – the final piece of the puzzle

The Problem

The DAWN Science project has an update site, but an install of the product does not have the site automatically appearing in the ‘Available Software Sites’. This makes it difficult for users to upgrade their DAWN installation. 
Before: Sites list is empty

Workaround

Users can manually add in the site, but would need to know where to find the site. So even if users have the site URL, this is still an unnecessary hassle and definitely a significant barrier to upgrade. 

Complications

Over the years the Eclipse upgrade mechanism has changed dramatically, culminating in the P2 framework. A simple google search provides lots of out-of-date information mixed in with the key information (hint: anything referring to features and update sites is pretty much deprecated). P2 is a powerful and therefore complex mechanism. Even P2 developers admit things could be better – from the Eclipse help on P2 metadata:
 Disclaimer: Authoring p2 metadata is something we expect to support with better tooling in a future release. 
Most update site tutorials available do not address this final step, probably because its a product deployment issue, beyond the scope of the tutorials in question. 

Solution:

P2 can be a complicated beast, but the key information is out there if you know where to look.
The solution is to create a touchpoint advice file, place it the appropriate location and configure it with the site information. 
For DAWN that boils down to creating a new p2.inf file which is colocated with the org.dawnsci.base.product file. The file is configured with the update site information – here’s the key bit of magic.
This is essentially adding in a line with the instructions.configure key and the value in the specified format – see here for details
After: Sites list automatically populated with DAWN update site

Testing:

As ever, testing is the trickier part of the job. Using the existing Squish framework, two tests are added in. 
The first test launches DAWN and makes sure an update site is listed. This test ensures the list is not empty, it does not check the content of the list. While a check could be added to check the value of the site, this would make the test unnecessarily fragile and require updating every time the site is updated.  However, the content of the list of sites is added to the test logs to provide room for further checks if desired in the future. This is a regression test to ensure the codebase never reverts to the original problem. 
The second test actually provides a smoke test for the update site itself. This test launches a previously released version and then runs a full update against the DAWN p2 update site. The test passes if the p2 infrastructure returns success and DAWN restarts successfully. (Note this test is pending as it first requires the actual site locations to be approved).

Resources: