iOS 7 - User Interface Quirks

I'm liking the new interface with iOS 7 ... but am still amazed by the lack of consistency.

It's even worse when Apple itself slips up. 

For example: my auto update setting updated the iBooks app recently, to version 3.2. In general, a cleaner, simpler look. But, I was surprised when I hit the Store button, and saw the icons along the tab bar at the bottom:

For some strange reason, the current tab has a glow effect - in addition to the blue highlighting. Strange.

What makes it even stranger is the lack of glow in other apps. For example, here's the App Store - showing the version history for iBooks itself ... 

Strange indeed.

For reference, the Apple design guidelines for tab bar icons are here.

Irrigation Repair 101

Third in my series of home repair items ... the rain sensor for my irrigation system. The function of the sensor is to detect rain - and then inhibit the operation of the irrigation system for a period of time, so that the system is not on unnecessarily.

It had needed to be relocated from it's old position - and as part of reconnecting it, I though I'd test it as well.

Unfortunately, it didn't want to work in the new location. Rather than buy a new one, I thought I'd open it up and see what the problem could be.

They are quite simple devices ...

• a sensor, which consists of a number of fabric type discs stacked on a rod
• when the discs are exposed to water they expand
• which in turn presses a micro switch

I disassembled the unit - and tested the micro switch - which was all ok. This particular one has the three leads: 

• one common
• one for a normally open circuit
• one for a normally closed circuit

This picture shows the bottom of the pole protruding into the chamber which houses the micro switch.

The discs themselves also seemed fine. I gave everything a clean, and reassembled.

And here finally is the result - the irrigation controller showing the rain symbol.

I can only guess that the process of relocating the sensor disrupted it in someway. But, a working sensor makes for a happy gardener.

Door Chime Repair 101

Following on my theme of repair, rather than throw away and replace ... my attention turned to my door chime - which had not been working properly for a while.

It's a simple model - an Arlec DC371 - $35 retail. After changing batteries in the receiver and transmitter, it was still not cooperating. But, in looking around inside the transmitter, I inadvertently pushed the button to select the tunes - and it sprang in to life.

So, I knew we had some basic functionality. I returned to the circuit board, and inspected the main micro-switch for the pushbutton. It had two leads protruding from the other side of the circuit board - so I shorted the switch output with a screw driver, and hey presto - it worked.

The cuplrit was the micro-switch. And they don't call them micro for nothing.

It looked a little daunting. The top plastic retainer was fixed by 4 little plastic lugs. I sliced those off, and underneath was a small plastic button, sitting on top of a flexible metal disc - which was slightly convex, so that it clicked when depressed.

Under the disc were 3 contacts - two at the sides, and one in the middle. When the disc was pressed, it closed the circuit between these contacts. I removed the disc, and tried shorting the contacts with a screw driver but this didn't seem to work.

I gave the contacts and the disc a good scrape with a sharp knife, and a clean with some vinegar. And this seemed to be enough to allow the contacts to work. Result.

The tricky part was re-assembling the switch, since I'd cut off the tops of the lugs. I turned to my trusty super glue - but the first attempt failed - since it seemed to find it's way in to the mechanism.

I broke it down again, cleaned the parts, and tried again. This time was successful.

So, it's now back in operation. No more complaints from family and friends that the door bell isn't working.

I know I could have bought a new one ... but it's the principle, right?

Helvetica and Italics - at Central Station

Ok, so I've been meaning to put this up for a while. As a follow on from this post: commuting-with-helvetica ... I've realized that the station I'm at every day - Central - is a prime culprit of the Helvetica / Italics phenomenon.

I would love to know why:

• people do this
• how Queensland Rail can roll out a rebranding exercise, and not have consistent signage.

To recap - here's the original picture from Graceville station:

Toaster Repair 101

Dualit Combi

This is the story of one of my favorite kitchen appliances ... my Dualit toaster.

It's a Combi 2+1 model, and has given almost 20 years of faithful service - until the other day when the centre element shorted and died. Needless to say, it caused a bit of a calamity in our household. I've had it since the early nineties, when it was received as a gift from a wonderful friend in London.

Fortunately, I’ve long known that the simplicity of it’s design is one of it’s virtues. No electronic circuits. No fancy lights or displays. Just a simple mechanical timer. And most importantly, nearly all of the internal parts are user serviceable. I turned to Google in the first instance but was surprised to find no local distributor of parts in Australia.

But I did find what seemed to be a fairly reputable distributor with quite a shop front on EBay in the United Kingdom. I downloaded the instruction manual as a PDF document - which illustrated how to access the slots which hold the toaster elements. And how to replace the elements as well. This also showed the simple coding scheme which allowed me to match up my broken part with the appropriate replacement. I placed the order (which was around 20 dollars) and received it about 7 days later.

Inside - showing slots

I needed to wait until the weekend to find the time to devote to the replacement process - which is ok, since that’s when our major toasting happens.

I'm pleased to say that the operation went without a hitch.  The only issue is that the centre element is more efficient than the sides, leading to a slightly less even toasting result - perhaps I should have ordered replacements for all of the elements at the same time.

But, it does make you think. The fact that this and many other parts could be replaced didn’t happen by accident - it was designed in.

It also reminds me of an article in the New York times I’ve read recently, which highlighted a concept of ”Repair Cafes” in Amsterdam. The article is here: http://www.nytimes.com/...

These are places where members of the public can bring broken appliances and a team of volunteers attempt to fix them. What a great idea.

Imagine what could happen if we had products which are designed to be repaired - and communities to help support them.

Exporting Graphs from neo4j

I've recently had a brief introduction to the Neo4j database - by way of the YOW 2011 conference in Brisbane.

It looks really interesting - so I set about performing a few experiments. One of which is taking a graph and exporting it for use via other tools.

For example, here's a really simple graph - shown via neoclipse:

Sample Graph

And the code to produce it is like this:

Node nodeA = graphDb.createNode();
Node nodeB = graphDb.createNode();
Node nodeC = graphDb.createNode();
Node nodeD = graphDb.createNode();
Node nodeE = graphDb.createNode();


nodeA.setProperty("name", "A");
nodeB.setProperty("name", "B");
nodeC.setProperty("name", "C");
nodeD.setProperty("name", "D");
nodeE.setProperty("name", "E");


Relationship rel = null;
rel = nodeB.createRelationshipTo(nodeA, RelationshipTypes.DEPENDS);
rel = nodeC.createRelationshipTo(nodeA, RelationshipTypes.DEPENDS);
rel = nodeD.createRelationshipTo(nodeC, RelationshipTypes.DEPENDS);
rel = nodeE.createRelationshipTo(nodeC, RelationshipTypes.DEPENDS);

Nothing exciting to see there.

So, using the Cypher language for querying, I thought I'd investigate how to dump the graph structure so I could export it.

Assuming that A is the starting point of our Graph - just getting the nodes which are related to A can be found via this query:

start n=node:concepts(name="A") 
match (n)<-[r]-(x) return x.name, r

Results are:

+-------------------------+

| x.name | r              |

+-------------------------+

| "C"    | :DEPENDS[1] {} |

| "B"    | :DEPENDS[0] {} |

+-------------------------+

2 rows, 978 ms

But, to retrieve the whole graph, I require all nodes which have a relationship with A. So another attempt is this - allowing for multiple depth relationships:

start n=node:concepts(name="A") 

match (n)<-[r:DEPENDS*1..3]-(x) return x.name, r

Results are:

+-------------------------------------------------+

| x.name | r                                      |

+-------------------------------------------------+

| "C"    | List(Relationship[1])                  |

| "E"    | List(Relationship[1], Relationship[3]) |

| "D"    | List(Relationship[1], Relationship[2]) |

| "B"    | List(Relationship[0])                  |

+-------------------------------------------------+

4 rows, 100 ms

However, this doesn't help to recreate the graph. To do this, I need each source and destination node - and the relationship. The next attempt makes use of the fact that you can specify a minimum cardinality of zero of the relationship predicate - which allows you to include the start node as well. Using this allows us to construct a query like this:

start n=node:concepts(name="A") 

match p1=(n)<-[rel:DEPENDS*0..2]-(x)<-[r:DEPENDS]-(y) 

return n, x, r, y 

Which returns results like this:

+-------------------------------------------------------------------------------+

| n                  | x                  | r              | y                  |

+-------------------------------------------------------------------------------+

| Node[1]{name->"A"} | Node[1]{name->"A"} | :DEPENDS[1] {} | Node[3]{name->"C"} |

| Node[1]{name->"A"} | Node[1]{name->"A"} | :DEPENDS[0] {} | Node[2]{name->"B"} |

| Node[1]{name->"A"} | Node[3]{name->"C"} | :DEPENDS[3] {} | Node[5]{name->"E"} |

| Node[1]{name->"A"} | Node[3]{name->"C"} | :DEPENDS[2] {} | Node[4]{name->"D"} |

+-------------------------------------------------------------------------------+

4 rows, 31 ms

From here, it's a small matter of programming to iterate through these results, and generate an XML representation (for example, GraphML style) - like this:


<graph start="1">
  <node id="1">
    <data key="d0">A</data>
  </node>
  <node id="3">
    <data key="d0">C</data>
  </node>
  <edge id="e1" source="3" target="1">
    <data key="d1">DEPENDS</data>
  </edge>
  <node id="2">
    <data key="d0">B</data>
  </node>
  <edge id="e0" source="2" target="1">
    <data key="d1">DEPENDS</data>
  </edge>
  <node id="5">
    <data key="d0">E</data>
  </node>
  <edge id="e3" source="5" target="3">
    <data key="d1">DEPENDS</data>
  </edge>
  <node id="4">
    <data key="d0">D</data>
  </node>
  <edge id="e2" source="4" target="3">
    <data key="d1">DEPENDS</data>
  </edge>
</graph>


The first column of the result - N - is simple used to infer the start node. In this case, it's "A" - as specified by the query.

TweetBot UI

After the recent changes to the official Twitter iPhone app, I've done as others have - and looked at options.

At the moment, I'm trying TweetBot - self described as a Twitter app with personality.

And I'm really liking it. The transitions, animations and sounds make for an enjoyable experience.

But, there's a few little things which I think would improve it even further - one of which has been annoying me slightly (disproportionately to it's actual impact) - and that's the shape of the custom back button.

Let me illustrate ... here's a comparison shot between TweetBot - and the standard iOS back button:

I've highlighted the "problem" area - which shows:

• the standard button has a much steeper angle, and finishes with a slight curve to the line
• the TweetBot button is essentially a straight line (of a shallower angle) with a small curve at the end.

Like I said - not  a major issue. But every time I see it, I think how it would be nice to have it as the standard shape.

Commuting with Helvetica

Wow, Queensland Rail have recently upgraded their corporate branding - but it's only now that they seem to be rolling out the new station identities:

New Station Signage

And, they seem to have chosen Helvetica for the station signage as well - one of my favourite fonts. Who would have thought we would finally get some good design in our every day commuter life?

Strangely enough, some stations which have recently received new signs have had a similar version - but in italics! Quite bizarre. I'll update the post when I can take a picture.

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.

Getting started with XProc using Eclipse

This post looks at how to get started with Norm Walsh's XProc implementation - using Eclipse.

XProc is an XML Pipeline Language, which is being defined by the folks at the XML Processing Model Working Group. Norm has an experimental implementation, hosted at https://xproc.dev.java.net/. The release notes are here.

Naturally enough, this is as a Netbeans project - but I thought I'd give it a try using Eclipse. It was pretty easy in the end:

1. Start your favourite Eclipse version - I used 3.3
2. Add in a Subversion plugin (since dev.java.net uses subversion). I've been using Subclipse lately. See http://subclipse.tigris.org/ for more details.
   
3. Point your SVN explorer to the repository https://xproc.dev.java.net/svn/xproc
   
4. Check out as a new Java Project using the Wizard.
   
5. Download (some of) the required frameworks ... I found that I could get by with Saxon 6.5 and Saxon 9 to get started. Add these .jars to the build path. Also note that you should add saxon9-s9api.jar as well as saxon9.jar.
   
6. Adjust the build path - so that these two directories are used as the java source:
   
   java/src
   java
   
   The second is required, since a number of configuration files are referenced using a path like /etc/configuration.xml and as such, they need to be findable on the classpath. Eclipse will make sure that you exclude java/src from this include. Your classpath should look something like this:
   
   
   
7. I used the xproc.Driver class to do a simple test. It was not long before I realized that things were not happy due to my running on a Windows box. I needed to change this line:
   
   hash.put(port, "file://" + fn);
   
   to this:
   
   hash.put(port, "file://" + "/" + fn);
   
   
8. I then needed to use this sort of command line arguments:
   
   -i source=c:\fred.xml java/samples/count.xpl

This just runs the count pipeline against a simple xml document.

Simple.

Here's a screenshot of the project contents:




Note that some errors are shown (since not all required libraries are provided), and that all three of the saxon libs are required.

And for good measure, here's a screen shot of a successful run:

Declarative Eclipse Branding with SVG

Recently, I had need to add some Eclipse branding graphics to an RCP application.

Rather than take the "easy" route of using an image editor, I thought I'd explore the use of SVG to produce the required images in a declarative kind of way.

Using SVG for this purpose has a number of advantages ...

• they are cross platform
• the declarative, text file nature allows the content to be generated
• they can be created using open-source tools

The downside is that the bitmaps required for Eclipse branding must be in BMP format - not the newer PNG alternative. This is covered in detail in this Eclipse bug report - https://bugs.eclipse.org/bugs/show_bug.cgi?id=21315.

Fortunately, this can be overcome by converting the SVG images to a bitmap format by using a conversion program called a "rasterizer".

A good example of a rasterizer is Batik - an open-source toolkit for manipulating SVG images.
See http://xmlgraphics.apache.org/batik/tools/rasterizer.html for further details on the Batik rasterizer.

Round Trip example

Here's a simple example of some SVG source to get started.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="500"
height="330"
id="drawing">

<defs>
<g id="mytext">
<text
xml:space="preserve"
style="font-size:40px;font-weight:normal;text-align:start;line-height:100%;text-anchor:start;font-family:Bitstream Vera Sans"
x="200" y="125">Hello</text>
<text
xml:space="preserve"
style="font-size:40px;font-weight:normal;text-align:start;line-height:100%;text-anchor:start;font-family:Bitstream Vera Sans"
x="200" y="170">World ...</text>
</g>
</defs>

<rect style="fill:black" width="500" height="330" x="0" y="0" />
<use xlink:href="#mytext" style="fill:white" />

</svg>

This produces a result like this:


In order to produce this image for the web, I used the Batik rasterizer. For example, the command I used was this:

C:\>java -jar c:\jshare\batik-1.7\batik-rasterizer.jar drawing5.svg
About to transcode 1 SVG file(s)

Converting drawing5.svg to drawing5.png ... ... success

Once you have a PNG format image, it's a "simple" matter of converting that to a BMP format. The simplicity involved depends on your platform:

• if you're on Windows - you can use Microsoft Paint: open the PNG and then save as BMP
• if you're on Linux - you can use GIMP

Refining your Image

Well, that's produced a very simple image. But one of the advantages of SVG is that you can get very nice effects with a minimum of effort.

Step 1 - Background Gradient

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="500"
height="330"
id="drawing">

<defs>
<g id="mytext">
<text
xml:space="preserve"
style="font-size:40px;font-weight:normal;text-align:start;line-height:100%;text-anchor:start;font-family:Bitstream Vera Sans"
x="200" y="125">Hello</text>
<text
xml:space="preserve"
style="font-size:40px;font-weight:normal;text-align:start;line-height:100%;text-anchor:start;font-family:Bitstream Vera Sans"
x="200" y="170">World ...</text>
</g>

<linearGradient id="top">
<stop offset="0%" style="stop-color: black;"/>
<stop offset="100%" style="stop-color: #484848;"/>
</linearGradient>

</defs>

<rect style="fill:url(#top)" width="500" height="330" x="0" y="0" />

<use xlink:href="#mytext" style="fill:white" />

</svg>

This produces a result like this:



Nice enough, but the default direction for a gradient is from left to right.

Step 2 - Background Gradient - in the correct direction

Here, we use another gradient - with a direction specifier - and embed the first.

<linearGradient id="top">
<stop offset="0%" style="stop-color: black;"/>
<stop offset="100%" style="stop-color: #484848;"/>
</linearGradient>

<linearGradient id="topa"
xlink:href="#top"
x1="0%" y1="0%" x2="0%" y2="100%"/>

</defs>

<rect style="fill:url(#topa)" width="500" height="330" x="0" y="0" />

This produces a result like this:



Step 3 - Background Gradient - with a horizon effect

This refinement adds a horizon - by splitting the image in two - at 200 px down, and using two gradients.

<linearGradient id="top">
<stop offset="0%" style="stop-color: black;"/>
<stop offset="100%" style="stop-color: #484848;"/>
</linearGradient>

<linearGradient id="topa"
xlink:href="#top"
x1="0%" y1="0%" x2="0%" y2="100%"/>

<linearGradient id="bottom">
<stop offset="0%" style="stop-color: #707070;"/>
<stop offset="100%" style="stop-color: black;"/>
</linearGradient>

<linearGradient id="bottoma"
xlink:href="#bottom"
x1="0%" y1="0%" x2="0%" y2="100%"/>

</defs>

<rect style="fill:url(#topa)" width="500" height="200" x="0" y="0" />
<rect style="fill:url(#bottoma)" width="500" height="130" x="0" y="200" />

This produces a result like this:



Step 4 - With a Graphic

Naturally, if we are doing a nice, modern style image, we should use some modern styled clip-art to give the image a lift. Since we are using SVG, there is a whole world of choice at the Open Clip Art project. For my Hello World example, I've chosen a nice clean globe.

In order to use a graphic, download the source to separate file. It can then be included in two different ways:

1. cut and paste the source code into your SVG file
2. save it to a separate file, and reference it as below using the image tag.

Note that I have applied a scale transformation to make the image fit in.

<g id="globe">
<image xlink:href="globe.svg"
width="500" height="500" x="0" y="0"
transform="scale(0.25)"/>
</g>

</defs>

<rect style="fill:url(#topa)" width="500" height="200" x="0" y="0" />
<rect style="fill:url(#bottoma)" width="500" height="130" x="0" y="200" />

<use xlink:href="#mytext" style="fill:white" />
<use xlink:href="#globe" x="60" y="80" />

This produces a result like this:



Step 5 - With a Reflection

No self-respecting modern image would be complete without the "reflection" technique! This is amazingly simple using SVG - just apply a transform effect on the use tag.

<use xlink:href="#mytext" style="fill:white" />
<use xlink:href="#mytext" style="fill:white;opacity:0.25" transform="matrix(1 0 0 -1 0 400)"/>

<use xlink:href="#globe" x="60" y="80" />
<use xlink:href="#globe" style="opacity:0.25" x="60" y="80" transform="matrix(1 0 0 -1 0 400)"/>

This produces a result like this:

Photoshop Elements - Explorer

As a way of investigating the internals of the Adobe Photoshop Elements (PSE) meta tags, I thought I'd whip up a little Eclipse plug-in to do some experimentation.

The primary purpose was to provide a means of exporting my metadata. I do a little editing within PSE, but my largest investment is in the metadata attached to (almost) every photo.

I realize that you can (and should) backup your PSE catalog using the supplied tools, but this approach also provides a degree of independence should I ever wish to decamp to another product.

Plug-in Structure

The following diagram shows the plug-in dependency hierarchy. The diagram was produced using the brilliant Plug-in Dependency Visualization Tool from Ian Bull, also described here on his blog.



As can be seen from the hierarchy, I make use of a number of libraries, packaged as plug-ins.

• XOM - to provide XML support. See here for more details on XOM.
• SQLite JDBC driver. See here for more details.
  

I had a few choices about how I was going to deploy it - workbench, RCP or even scriptable via Eclipse Monkey ... but I thought the workbench plug-in would be the simplest thing to get started.

Workbench Integration

Since I was aiming for the workbench, it made sense to provide some integration with the functionality you get for free! The two most obvious points are:

• workbench properties
• an image viewer
  

It's very easy to integrate with the workbench Properties View. This is very well documented - in particular in this article.

I have also encountered a great image viewer, courtesy of Wayne Beaton - see here for more details.

The great thing about making use of these functions is that they simply require an adapter to the required class to exploit the functionality.

• the Properties View needs an adapter to an IPropertySource implementation
• the Image View plug-in requires an adapter to an ImageProvider implementation.

To keep things simple, I initially coded up the getAdapter code directly into the model - but, with a teeny bit of thought - and prompting from Wayne's latest "adapters" articles here - it made sense to extract them into an AdapterFactory. And after doing this, it made sense to extract the whole model to it's own plug-in.

Plug-in Functionality

It's pretty basic - a simple PSE Explorer View, which lists the contents of the catalog, and two menu options:

• one to load an existing PSE catalog file (SQLite database)
• one to export the loaded PSE catalog as an XML Document.

The following screen shot shows the plug-in in action - with the PSE Explorer view on the top half of the screen, and the properties and Image View on the bottom.



The plug-in functionality is initiated by the two command handlers (corresponding to the menu items) - that is, import and export.

The import function is facilitated by a simple DataProvider class. This provides the means of accessing the SQLite database and populating the model used by the viewer. The SQL used is similar to my earlier experiments.

The export function merely provides an XML transformer for the populated model. The results of the export looks like this:



Summary

This is just a starting point, but it has provided a easy way for exploring the PSE metadata. With a bit more polish, I'll see if I can release some of the code.

Photoshop Elements - User Interface

In my recent experimentation with Photoshop Elements 6 (PSE6), I was quite surprised by some of the user interface (UI) techniques employed.

For example, with the "Albums" and "Keyword Tags" palettes, there is a "New" button, as shown below - the bright green cross -



When you hover, the tooltip text shows as below:


But what if you wanted to collapse or expand the tree? There doesn't seem to be any actions available for that. Let's click the "New" button - which is a pull-down, and see what happens ...



Aaahhh. There they are. At the bottom of the "New" menu.

what the?

It seems that it's basically overloading that first tool bar button. I'm not sure why. For fear of cluttering up the tool bar perhaps.

An alternative would be to make the buttons explicit - perhaps like the Eclipse style ones shown here (as the boxed "-" and "+"):



A little more thought needs to go into style guides for these interfaces I think.

Photoshop Elements - Smart Albums

My investigations are continuing with Adobe Photoshop Elements 6 (PSE6). And this post looks at the new feature called Smart Albums.

They are based on the same concept as the Smart Playlist in iTunes. That is, they are defined searches - rather than specific, static items - so that the Album contents always stays current.

It is a good feature to include, and in general seems well done. But, I've encountered a few usability issues which seem important.

1. User Interface to Modify a Smart Album

This seems strange. The problem is that there are two different "edit" operations - the most obvious seems to be to select the Smart Album, and then the Edit toolbar icon. In this case, I've selected the album called "Smart Taxis".



Indeed, the hover text indicates "Edit Smart Taxis Album". When you select this action, you get a dialog which only allows you to change the name! It conveniently tells you about the criteria though.


To modify the search criteria, you instead need to follow this process:

1. Active the smart album, by selecting it from the Album palette
2. From the organizer, select the Options pulldown
3. Then select "Modify Search Details"
4. You then, finally, see the dialog - which is entitled "Find by Details (Metadata)"
   
5. You then still need to make the changes you need, and if you want to change that same album, select the check box and type your original name, and press "Search" ??
   
   
6. A helpful dialog then tells you that this album exists, and would you like to replace it.
   

OMG! In doing this post, I've just realized that it doesn't replace your album - PSE6 adds another album - with the same name.

To be slightly fair, the dialog text doesn't actually say it's going to replace that album - it says "Click OK to create a Smart Album with this name anyway". I guess it could be seen as helping to provide some form of version control. But still, it doesn't seem terribly obvious.

What's going on here?

It seems that there is a basic disconnect between the two halves of the screen - the Organizer on the left - with the find bar showing Search Criteria - and the Album palette on the right - which talks in Albums.

2. Smart Album search criteria

Unfortunately, some of the search criteria available seems a little restrictive - that is, a bit lacking in flexibility. Some examples may help to illustrate:

1. Can't use "not Include" with the "Keyword Tags" search - only Include:
   
   
   
   
2. Can't use Smart Albums as the argument with the "Albums" search. The only albums presented in the list are standard (static) Albums.
   
   
   
   This would allow for a tree structured, or nested style search. This is also something which iTunes seems to manage ok.
   

I'm sure there are others, but these are the ones which seem to leap out.

Conclusion

Smart Albums is a good start - but it would nice to see them just a little bit smarter ... and easier to use.

Exploring the PSE6 Database

Curiosity has got the better of me, and I needed to see a little bit more of the Photoshop Elements 6 (PSE6) database.

You can use standard SQL to poke around, but for simple things I found a great tool in SQLite Expert Personal. It's a simple database exploration tool. The main screen looks like this:




Naturally, I also needed to try some SQL too. This query retrieves the Star rating (from 0 to 5) for all images:

select media.id as recid, media.full_filepath
, mdint.value as rating
from media_table as media
join media_to_metadata_table as mm on media.id = mm.media_id
join metadata_integer_table as mdint on mm.metadata_id = mdint.id
join metadata_description_table as mdesc on mdint.description_id = mdesc.id
where mdesc.identifier = "xmp:Rating"
and mime_type = "image/jpeg"

Another test query is to retrieve the user tags for an image:

select media.id as recid, tt.name
from media_table as media
join tag_to_media_table as t2m on media.id = t2m.media_id
join tag_table as tt on t2m.tag_id = tt.id
where media.id = 276
and type_name like 'user%'

I think that I'll put these to further use soon.