Google Code - Part 1

As I've mentioned earlier, I'm using Google Code to host the apselex project - an Adobe Photoshop Elements Explorer.

It is very easy to get started, and quite easy to use.

But, one thing was eluding me - how to use images in the wiki. I know - the help page has some examples, but as with all these things, the devil is in the details.

• the image needs to be an external link
• as such it needs to be hosted, and available
• a "makes sense" approach is to store images in the wiki directory itself
• and then simply point to the image with a link like this:
  
  [http://apselex.googlecode.com/svn/wiki/ScreenshotExplorer.png]
  

Simple!

Naturally, using Eclipse, it was pretty straight forward to put some images in this directory. The approach I took was:

• create a separate Eclipse project - mine was called ApselWiki
• share this as a Team project (using subversion), and use the wiki as the URL
  
  https://apselex.googlecode.com/svn/wiki
  
  Note, that the wiki directory is outside the /trunk directory. That is, it's in the root of your project.
• You can then simple paste new images into the Eclipse project - and also edit your wiki pages if you really like.
  
• Then simply perform a "Team -> Synchronize"
  

Easy!

Photoshop Elements - Explorer Part 2

Due to overwhelming demand (well, at least 1 person :-)), I've put up my initial code for exploring the Photoshop Elements database. For a small bit of background info, see my previous post.

I thought I'd give google code a try for hosting - as such, the project is located here.

Drop me a line in the comments if you're interested in participating.

Real World Usability

This is a post on usability - in the "real world" - which may become something of a series.

The subject today is a ticket vending machine - not super exciting, but it's a a new model being rolled out in south east Queensland, so could be considered topical.

First, a picture:



Mmmm, what ever could be a problem with this shiny new design.

Well. A few things unfortunately. Let's see.

1. the coin slot. There's not enough room for a right handed person to insert coins, without constantly scraping them up against the side of the machine. Why?
   
   
   
   
2. the "ticket/change/receipt" hopper is too low. I understand that the machine needs to cater for people of all heights, including wheelchair access - but this is just too low. It requires constant stooping to fetch change and tickets.
   
3. the touch screen. I'm not sure where to start with this one, since there are so many aspects ...
   
   1. the responsiveness (or lack of). there's a lag in the response - so that after you've pressed a soft button, you're not really sure if it's really pressed or not
   
   
   2. the angle - unless your eyes happen to be perpendicular to the screen, your screen presses will be off the mark - it seems that there is enough of a gap between the surface of the touch screen, and the actual LCD screen that this is a real problem.

Then there's the interaction flow. The series of screens you have to wade through to get a ticket is just plain cumbersome. Some issues are:

1. To select a destination station, you need to go through a multi level alphabetical menu, or select from a "map". The map isn't too bad, but in combination with the "angle" problem, it's a little hard to use as well.


2. There are no direct keys for common stations


3. why not allow a one touch "daily to Central" from suburban machines?

I realise that these concerns will not be as prevalent once the smartcard side of things is operational (since most commuters will just use them to top up the value on their cards) - but they will still be relevant for paper tickets.

A little bit of research shows that these machines aren't a one off design for Translink - they're a customized version of an existing design which goes by the name of "Universal Vendor 1000". I wonder how much usability testing they did?

Photoshop Elements - Migrating to Version 6

Well, I thought my migration to Adobe Photoshop Elements Version 6 was complete - and I was very happy with the way things had gone.

Until, I needed to print one of my pre-migration dated images.

I was greeted the following, rather unfriendly dialog, and could not print.

Wtf? I was concerned to say the least.

I re-traced some of my steps ...

• newly edited photos would print ok
• new (Version 6) photos were ok
• old (pre-version 6) photos were ok
• old, edited photos were NOT ok

I smelled a rat with the migration process for edited images. The edited images had seemed to be imported as version sets correctly. I did a bit more checking. The following grab shows a typical (albeit) sample image:



Note that the original image in the Version set is selected, and the Size attributes are displayed correctly in the Properties window.

Now, have a look at this next one, with the newer image from the Version set selected:



I've highlighted the problem area - the image width and height are missing. This was pointing to all not being well with the edited image.

I waded through the information on the Adobe support site here, I couldn't find any exact match. I even resorted to the forums, which are extremely painful to use - and still no match.

So, I thought - there's nothing for it but to submit a bug report. This itself was fairly painless, but disappointing:

1. no reference number, or tracking information was returned.
2. no acknowledgment that a bug had even been reported (via email, for example).

However, I was determined not to be beaten by this. I went back to the support documents, and found that a number of suggested fixes finished with the recommendation to use the "Update Thumbnail" command. What the? I didn't think that this would be appropriate for me - since my thumbnails looked fine, thank you very much.

Well, I thought - what could possibly go wrong ?

I'm pleased to report that - it actually fixed the problem!! Woo hoo. I was a little surprised, but relieved to say the least. A few years of editing had not been lost.

I was wondering why I needed to do this though - I used the supported Catalog conversion process. If PSE needed my thumbnails to be updated, I would have preferred them to be done as part of the migration process.

However, this exercise did open my eyes to the strange support mechanisms provided by Adobe. When the product itself sports a gleaming new interface, it's a little sad that the support facilities are somewhat lacking - and in case of those forums, downright primitive.

If any Adobe guys are around - I guess you can close my bug report too :-)

Cheat Sheet Extensibility - Part 2

Oops.

I forgot to mention one of the little tricks required to make the cheat sheet actually usable - you need to be able to signal it's completion :-)

There are a few things required to make this happen:

1. the task requires a UI control which allows the user to signal that the task is complete. I used a form hyperlink control, similar to the following:

   ImageHyperlink link = toolkit.createImageHyperlink(
   form.getBody(),
   SWT.WRAP);
   Image img = AbstractUIPlugin.imageDescriptorFromPlugin(
   Activator.PLUGIN_ID, "/icons/complete_task.gif").createImage();
   link.setImage(img);
   link.addHyperlinkListener(this);

2. a reference to the task being edited must be obtained. Fortunately, this is made available when the setInput method is called. In this method, use some code like this:

   public void setInput(IEditableTask _task, IMemento memento) {
   task = _task;
   }

3. attach a listener to the control




4. when the link is activated, your listener will be fired. When this happens, the task should be set to complete. This is then just a simple method call using the task instance which has already been saved:

   task.complete();

Cheat Sheet Extensibility

I've been looking at the Eclipse Cheat Sheet capability recently - with a view to using it more as a workflow assistance tool, rather than a "follow these instructions" helper.
As such, the idea of crafting specific tasks that the user can interact with seems an appealing idea.
Here's a screen shot of a simple first attempt.


Note that I've used the Eclipse Forms controls to blend in with the "flat look" layout.
This was pretty easy to get going:

1. Define a task extension in your plug-in.
   

   <taskEditor
   class="mypdeproject.tasks.MyTaskExtension"
   icon="icons/sample.gif"
   id="MyPdeProject.taskEditor1">
   </taskEditor>
   

   
   
2. Define the class referenced above. It needs to implement org.eclipse.ui.internal.provisional.cheatsheets.TaskEditor
   
3. Implement the required methods. The main one of which is the createControl method - to create the UI controls used to edit the task.
   

   public void createControl(Composite comp, 
        FormToolkit toolkit) {
   
    form = toolkit.createForm(comp);
    form.setText("Hello, Eclipse Forms");
   
   }

   Obviously, you may want to define a few more fields in there than this.
   
4. Define a complex task, and then reference our newly defined task extension.
   

   <task id="t2" kind="MyPdeProject.taskEditor1" 
     name="Extended task" 
     skip="false">
     <intro>
      Introduction Extended
     </intro>
     <onCompletion>
      This is the Conclusion
     </onCompletion>
   </task>

And that's it! Simple really.
Next, I'll take a look at how you can use task variables to communicate between your tasks.