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”

What Good Tech Events Look Like

KidsAdoreDitchMy 5-year old son and I walked into the Village hall at Shoreditch, not sure what to expect after making the trek into London following a spur-of-the-moment sign up to Kids Adore Ditch. We needn’t have worried, because from our initial warm welcome it was a terrific day-out. And it had me thinking about how I wish all the tech conferences I go to were that much fun. Here’s what it takes:

1. A diverse crowd

The first thing that struck me was how nice it was to have such a mix of kids and tech side by side. The room was bursting with energy. And it wasn’t just boys, there were girls and plenty of them. At one point it seemed unreal as I was chatting with a fellow mum, discussing the pros and cons of the Eclipse IDE , with a quadcopter hovering nearby and a little girl doing snow-angels on the carpet. For me a that was a breath of fresh air from the normal male-dominated crowd at the conferences I normally frequent (added bonus: for once I was taller than half the people there). Continue reading “What Good Tech Events Look Like”

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