How I quickly evolved an initial concept of “an eye peaking through angled brackets” into a an icon for my small Web Intents Snooper chrome app.
I’m not a designer, but the tools that we all have available to us through our computers are simply incredible. So why not have a go?
I’ve been interested for a long time to find out how the chrome web store stacks up against Play (aka Android market) for app developers. So, largely by way of an experiment, I published my harmonica tuning tool on there today and I thought I’d capture some rambling observations in a blog post.
In what follows:
CWSDD = Chrome Web Store Developer Dashboard
PADC = Play Android Developer Console
(an aside: I’m sure it’s being worked on, but Google really needs to start unwinding some of the complexity that’s creeping into the naming of their developer services)
I wanted to start off with a small comment about packaging your web app for inclusion on the chrome web store: it’s incredibly simple. JSON+PNG->ZIP and that’s it. I’ve written a couple of chrome extensions for internal team use - that was super simple. This is even simpler.
The CWSDD uses the Google Webmaster site ownership verification tool to safeguard against people publishing other developer’s applications under their own apps. The only minor thing I tripped-up over was that using *:// requires verification of both http:// and https://.
This is a very specific tool that I doubt will garner even a small handful of users, so I’ll be honest: I dashed off an icon and the minimum number of promotional images I could get away with. Even then I struggled with the icon. The guidelines specify no perspective. Is there any way to draw a harmonica without perspective that doesn’t make it look like an abstract composition of shapes? Well, I politely sidestepped that guidance. It also felt odd producing just a single icon asset; I’ve become accustomed to creating multiple assets for Android app icons and have come to see it as as a feature.
The documentation for the CWSDD does an excellent job of communicating which assets you need to provide and why, and how you can expect they’ll be used. I don’t recall anything as clear as that for the PADC, but things may have improved considerably since I last read the docs. Of course the CWS has the advantage of not being required to support legacy clients over a wide number of form-factors, as the Android Play developers must.
There were no onerous requirements. I got away with supplying just two images, a small promotional image and a screenshot (this little app isn’t worth more).
There’s the usual angst as you try to pigeonhole your latest wunderapp into a category. The CWSDD has a significant edge over the PADC store here since it provides for a primary and a secondary category together with developer supplied tertiary categories. How these developer specified categories are actually used is unclear though. All the guidance says is “We will use them to improve our selection of categories.”
Personally I like the Google Code approach: free text labels but with the support of a large number of “common labels” (possibly clustered from the aggregate of those already supplied, I don’t know). I do think that would provide a good basis for categorizing apps and surfacing relevant ones to users.
In general, the process of uploading and publishing was very similar to that of publishing an Android app; both in terms of how the forms are presented and the flow that ties them together. On the whole I’d say that the CWSDD feels more ‘coherent’, but that the PADC clearly packs in more features.
Around publishing, the CWSDD shows up a couple of very basic deficiencies in the PADC. The first is that the CWSDD supports “trusted testers”. It appears to allow you to define your testers by membership of any Google Group you set up. I didn’t use it (this is a bit embarrassing, but I don’t actually know anyone else who’d want to use this app) so I don’t know how well it works in practice, but it looks like a very clever solution.
Secondly, CWSDD allows you to supply a Google Analytics ID to track user views of app listing (Google Code supports this too). It’s a real pity that PADC doesn’t do something similar; this is valuable information that Android developers are missing out on.
These are just my first impressions of the chrome web store developer dashboard, with an application that I think has a place in the store, but which is nevertheless very a modest app. I found it simple, well documented, and quite slick.
I will definitely design any future web apps with an eye to integrating them into the chrome web store and will also suggest it to relevant clients as a strong option (with the caveat that I don’t know how smoothly non-free apps operate).
I’ve just published a small online tool investigate different harmonica tunings.
http://www.tomgibara.com/harmonica/tunings/
As indicated by my previous two posts, I’ve recently become interested in learning about harmonica tunings. So I wrote a small tool that allowed me to analyze the chords that are available in a given tuning. Then I thought I’d share it, so I extended it with some standard tunings and gave it just a little polish.
Note that I’ve been hasty and haven’t taken any time to test it on different os/browsers/screen combinations, if anyone wants to report an issue, a comment on this post would be a good way to report it.
I’ve just finished designing a new harmonica tuning.
It’s difficult to say why. I think I just really enjoy finding elegant and balanced solutions to problems. A harmonica tuning provides a really excellent challenge - even if you’re mostly musically illiterate like me.
Firstly there are a number of rigid constraints: there are fixed number of holes and physical laws determine which combinations of notes they can provide.
Then you have to consider the perspective of someone playing the harmonica. What patterns of notes are easy to learn? and easy to hit? and easy to express with?
And then there’s the music that you’re trying to make it possible to play - it’s accumulated over centuries and it’s varied and untrammelled. You can’t fit much of it into the 10 holes of a harmonica, so some hard choices need to be made.
Now that I reflect on it, it’s very much like producing software: there’s the hard rules programming, the needs of the user to consider, and behind it all, a universe of things the user wants to achieve with your software, if you can just get it right.
I love developing software, and maybe that’s why I’ve enjoyed designing a harmonica tuning.
I recently started learning the harmonica. I’m rubbish at it, but am enjoying it hugely.
Mainly for the pleasure of it, I’ve taken a stab at designing my own 10 hole tuning, and I’m delighted with how well it turned out.
The tuning (shown above for C) spans very nearly three octaves and I guess it would be broadly classed as a spiral tuning.
The blow and draw notes on all holes are separated by a two semitones. This allows every draw note to be bent, but avoids any excessive difficultly that comes from having a larger interval (I’m thinking here of the 3 hole bends in a Richter tuning).
Central to this tuning is that every seventh note in the full chromatic scale is relegated to an overblow (consequently full chromaticity requires 5 overblows). This provides a rich and useful set of chords. Indeed, drawing or blowing on any three adjacent holes always yields a major or minor chord (which consistently alternate along the harmonica).
The tonic is available in the first octave on draw 1-3 (and it’s also available on blow 5-7). The dominant is adjacent on draw 3-5, with the subdominant available both major (draw 5-7) and minor (draw 2-4). I think that should make the tuning well suited to regular blues and rock.
I haven’t weighed up the negatives yet, two things are evident: there are no opportunities to play octaves, and the note pattern (though systematic) is different in all three octaves - so it’s business as usual there.
I just realized that when I count on my fingers, I count in binary.
How often as adults do we count on our fingers? Today, for the first time I can remember, I did. It was a reflex, and when I looked down at my fingers, I found myself (to my own surprise!) counting in binary patterns on my fingers.
My mind was jolted back to a dim memory: that in my teens, I made a concious decision that I would count binary on my fingers. The advantage was as obvious to me then as it is now. I can count to 1024 without pausing for thought.
I hope it didn’t take me long to learn since, as it turns out, I clearly haven’t needed the skill.
I just committed some rough source code for, amongst other things, ImageUtil.
You’ll find it in my Google code SVN repository
You need this code to create the colour charts I posted a couple of weeks ago.
It’s inside a Maven project, but you can probably just cherry pick this file and have things work:
And watch out for this possible issue:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4886732
I haven’t been able to track down all of the situations it occurs in.
Crinch has had another minor bump to version 0.7.2. This release fixes an issue that can prevent some character sequences being returned from tries.
Some computer generated eyes. Based this early work.
Thankfully, I’m better at coding than drawing, otherwise there would be no hope.
