Archive for August, 2009

Photoshop Tutorial: Masking Logos from the Web

// August 24th, 2009 // No Comments » // Creative

Often I seem to have a need for a low-res company logo that I want to use against some colour that isn’t their web site’s normal background – eg. when creating mobile interfaces:

Most companies don’t seem to give out vectors of their logos, so if you can’t find one you usually end up in Photoshop trying to cut one out – and it was never 100% obvious to me how to replace the fixed anti-aliassing with nice alpha transparency.

Aside: Powerpoint 2007 does now make a nice attempt at letting you remove picture backgrounds, but it doesn’t fix the anti-aliassing and it breaks down when it encounters JPEG artifacts.

So, finally, I decided to work out how to do it properly.

Step 1 – load the logo into a new Photoshop Document

The original logo, nabbed from the web, which was (inexplicably) a JPEG:
Original logo

Zoomed in to show JPEG artifacts and fixed anti-aliassing to the white background:
Original logo, enlarged

Load into Photoshop, and paste into a new Photoshop document (don’t work within the original JPEG) – this is the layer palette after the import:
Photoshop layer palette with logo

Step 2 – create a new Layer Mask

In the layer palette, click on the “circle inside a rectangle” icon; the layer preview should now show a second empty rectangle to the right of the logo preview itself:
Adding a Layer Mask in Photoshop

Step 3 – Edit the Mask

Select all and Copy the current picture, then shift to the Channels tab:
Select Channels tab

Click on the eye icon next to the Layer Mask channel, and unselect the eye next to the RGB channel:
Show the Layer Mask channel only

The image should be greyscale, looking like this:
Layer Mask preview

Any pixel that is white in the layer mask will be fully opaque in the layer, anything that is black will be fully transparent, and any grey will be translucent. So, with our current mask, the white background will be visible but the logo itself will be almost transparent. Hit ctrl+I to invert the Layer Mask colours:

That’s better, but the logo will still be partially transparent. We need to boost the contrast of the mask, to make the text white on black (with a little grey anti-aliassing round the edge of the text, which will become nice transparency). Go to Edit menu > Adjust Curves:
Adjusting curves to improve Layer Mask contrast

Note that we are deliberately ‘clipping’ – forcing the grey to go fully white, by making the curve hit the top of the box. You can also clip a little on the black end (bottom left) to force JPEG artefacts on the background to disappear (not shown here).
The text now looks good, but the graduation on the right is not so nice – we need to boost the contrast else it’ll disappear completely. Select just that part with the lassoo tool and then Edit > Adjust Contrast:
Adjusting contrast on the graduation

Step 4 – Remove the Old Anti-Aliassing

We now have a logo with a properly transparent background – to see it, reselect the RGB channel and unselect the Layer Mask channel. You should switch back to the Layers tab and select the actual left-hand layer preview – instead of the right-hand mask preview – now:
Layer palette showing mask and preview

Zoom in a bit for the next stage – the image should look like this:
Masked preview

The anti-aliassing is now using alpha blending, but the pixels being blended are still much lighter than the logo itself – so it will still not work properly against different background colours. This is now easily fixed though – select the name like so:
Select the name in the logo

Then select the text colour, choose a large flat paintbrush, and paint over the whole logo. The edges should darken to the text colour, like this:
Name, after colouring in

The name will now blend properly, look a little crisper around the edges, and we have also painted over all the JPEG artefacts to create solid colour – bonus! Next we do the same to the graduation on the right:
Graduation, after colouring in

Step 5 – Export as PNG-24

We now have a crisper cleaner version of the logo. All that remains is to export in a useful format which will actually preserve that alpha blending – which has to be PNG-24. File menu > Save For Web > PNG-24, with transparency. Voila:
The final PNG

For most of my day-to-day purposes, this is “good enough” – though obviously for full high resolution print work, you’re going to have to hassle their marketing department for a vector!

Name and Shame: Halifax helps enable Identity Fraud

// August 14th, 2009 // No Comments » // News

I just got a cold call to my personal mobile from one of the UK Government’s new acquisitions, Halifax bank. I was expecting an unrelated business call, so when I saw an unknown number I answered a bit more formally than is my usual wont; the conversation went something like this:

Me: “Hello, Tom Godber speaking”
Them: “Er… (pause)… is that Tom Godber?”
Me: “Speaking, yes”
Them: “Right. It’s about your (financial product), but I have to ask you some security questions first. Can you tell me…”
Me: “Hold on, who are you?”
Them: “Oh, it’s Halifax. I need to ask you security questions to prevent fraud. So, …”
Me: “Prove it”
Them: “Sorry?”
Me: “Give me something to prove you actually are Halifax. You could be anyone. Tell me the exact type of (financial product) I have with you, and then I’ll answer your questions.”
Them: “I can’t do that, for security reasons.”
Me: “OK, give me a number I can externally verify as belonging to the Halifax, which I will then call you back on.”
Them: “I don’t understand. If you just answer the questions I can tell you what this is about…”
Me: “No. I don’t know who you are and you refuse to prove your identity so I won’t tell you any of my secret information. What I need you to do is tell me which department you are in, and your name, and I’ll call you back via the number listed on the Halifax website for that department. Then I know I am speaking to the Halifax.”
Them: “Don’t worry sir, we sent you this information in the post as well and it requires no action. Have a nice day.”

I would like to ask Halifax how exactly this is different from the script an identity fraudster would use – a sufficiently compelling caller talking to a sufficiently incautious or distracted victim could easily compel the handover of enough information to compromise an account, and Halifax are training their customers to fall for it!

The eagle eyed will also note:

  • The only personal information the caller gave me was my name, which I had already given them when I answered;
  • I was forced to confirm that I had this financial product with a bank somewhere, unless I just hung up – but it could have been an urgent call, so it’s unlikely anyone would hang up without finding out more;
  • Had I not asked which company the caller was from, they could almost certainly have tricked me into revealing which provider I had this product with; the guy didn’t even say he was from Halifax at first!
  • Caller ID can be spoofed, so the number displayed on my mobile is no guarantee of anything (even if I knew what number Halifax’s call centres used).

One can only conclude that Halifax bank would like customers to give out all of their secret identity information to any person who calls up and asks about any financial product.  This is absolutely appalling, and you can bet they’ll try and squirm out of any responsibility when victims of identity fraud have to spend months of their own time picking up the pieces.

Bootnote: there was indeed a letter sitting on my doorstep when I got home, from the Halifax.  It detailed how much money Halifax had lost for me with this financial product over the last 6 months, and encouraged me to start putting more money in to gain further benefits.  So this whole thing was really just a sales call, with all the benefits on their side and all the downsides on mine.  Shocking.

Carnival of the Mobilists 186

// August 13th, 2009 // Comments Off // Mobile

My Orange post was featured on this week’s Carnival over at All About iPhone – check it out for the week’s best mobile writing!

Orange Customer Communications – the Ups and the Downs

// August 5th, 2009 // No Comments » // Mobile

Roaming

I just received the following SMS from Orange, which they no doubt felt was extremely helpful:

Hello. From 7 Sept making & receiving roaming calls in zones 3-7 will have a min 60 second charge then charged per second orange.co.uk/business/roamingupdates

I do like the idea of at least proactively telling your customers when you unilaterally renegotiate the fees you charge them, but as a Londoner my initial reaction was “They’re going to charge me for taking calls outside of zone 2??” This is relatively pertinent as I’m going for a dinner in Putney tomorrow…

A note for non-Londoners: the city is divided into zones for public transport purposes, and anything outside of zone 1 is pretty much not really London.  Arguably even west zone 1 doesn’t really count.

London transport zones

A note for Americans: public transport is a novel system enabling movement around a city without driving a car, leading to a much more compact urban design where every shop doesn’t need a vast car park in front of it, and walking from shop to shop is achievable and encouraged (keeps the weight down too).

You can kind of understand the concept of non-London being roaming, because there’s no need to go there most of the time, but it does seem a little cheeky as the regions are often quite pleasant in the summer and they are technically also part of the country.

Another note for foreigners: unlike most countries, the UK’s first city takes a disproportionate share of everything as the governmental, administrative and business capital of the country; it can make a claim to be the cultural capital too, though some of the other cities could try and argue that one. People outside London tend to resent it for that, and Londoners tend to ignore them because they’re not in London.

This post has meandered some way off topic, but at the start I mentioned a text message from Orange.  My point really is that sending out something like that was pretty meaningless, and actually only caused confusion.

How was my roaming billed before?  I remember before the EU got involved it used to cost me more than a quid just to pick up the phone in Estonia, and a number of telephone salesman got extremely rude responses because of this.  Apparently it ought to be cheaper now, but talk of per second billing just encourages me to say less even though actually it probably means it’ll cost less, maybe.  Fundamentally, does anyone care enough?  If you’re on a business phone you just talk, if you’re not you get the hell off the line asap. It’s nice to know that there is a mathematical function applied to come up with the cost, but if it can be changed unilaterally like this and requires counting of seconds it’s unlikely most people will bother to worry about the details.

Possibly the zones are tied to DVD region zones? At least I’d have some hope of knowing what they meant that way.

Data Bundles

On to more of a successful communication from Orange.  Yesterday they rang me up for a halfway contract review (9 months to go – I much preferred the old style 12 month contracts, but apparently to get an N96 I had to plump for 18; how they must be laughing).  Apparently, we could save over £50 a month if we got data bundles.

This makes complete sense – we have testing SIMs downloading apps all the time, and Ben and I also use data a lot – but it’s somewhat ironic as 9 months ago we actually signed up for “unlimited” data bundles.  A few months later I called to ask why we were beiong charged so much for data when we were on unlimited bundles and they denied any knowledge of such a thing, saying we could add bundles if we wanted for something like £30/month/SIM – pretty ridiculous.  They had some other prepay bundles which were slightly more expensive per Mb than the usual per Mb charge, and that was it.  We declined.

Fast forward half a year and Orange data bundles are back, and fairly cheap.  We now have them, allegedly (I’ll be checking in a few months) and will be saving money, all at Orange’s recommendation.  This is a vastly more helpful and welcome communication than the news that Putney will incur roaming charges.

App Testing

Orange also have a testing centre, where you can borrow their handsets to test your apps.  We looked into it for FrontlineSMS and found in the UK there was not one phone from the last two years.  Plenty of old phones are still in circulation – that’s why we always support them at Masabi – but plenty of new ones are too!  Why do they bother?

On the other hand, they will now test and sign any Java apps they really like for their App Store, free of charge.  That’s a huge boost, as thusfar operators have tended to view the QA and signature steps of an app store as a means of revenue generation, gouging the developers at every step. There are alternative ways to explain what they do, but it’s hard to see it any other way if you’re not an operator yourself!

Mobile Webapps – iUI Framework Extensions

// August 3rd, 2009 // 10 Comments » // Mobile, Web

As I explained in my earlier Masabists post, I’m finally able to show off some of the work I’ve been doing recently on local mobile webapps.  We’ve based our webapps on the rather excellent iUI framework, which has a great philosophy:

  • Clean, standard HTML markup;
  • Very lightweight – one CSS stylesheet and a single Javascript file;
  • Built-in AJAX support, so form values can be submitted and HTML fragment responses pasted into the document structure;
  • iPhone native-style look and feel, including slick screen to screen transitions and screen rotation support.

The screens are all embedded inside a single HTML file, which has two advantages:

  1. You get very rapid movement around the app, with no need for a reliable network connection and none of the slowdown associated with downloading every page;
  2. You can cache the app using an HTML 5 manifest, so even when the user has no network signal they can access the site.

This is great as far as it goes, but there were a number of screen types not supported.  I have added an optional extension script, following the same philosophy, to add them – this ost is just a reference point to describe what the extensions do, when discussing merging them into the framework.

Structure

The extensions are in a seperate script and CSS file, which creates the window.iui_ext object, much like the core iUI framework itself.

To work, iUI has been extended in one key way – it now fires off Javascript events to screens, specifically:

  • onFocus() is called whenever a screen is made visible;
  • onBlur() is called whenever a screen is left.

Both events are called at the point where the link is clicked and the sliding transition begins.

Adding the events gives the developer a huge amount of extra scope for controlling the webapp, which is then used to create the additional webapps without breaking away from clean markup.

Form Handling

The iUI extensions automatically add focus and blur event handlers for every form, which store all field values in a name/value store whenever a form is left and restore the values whenever a form is visited again.  These are added inside the iUI code, and once finished they will call any explicitly defined onFocus="..." / onBlur="..." attributes within the markup.

The map follows the same basic semantics as the HTML 5 sessionStore object, which I wanted to use but sadly it isn’t implemented on the iPhone yet (the latest desktop Safari seems to have it though).  The methods are exposed through the iui_ext object, for example window.iui_ext.getItem('key').

The purpose of this store is to allow the movement of values between screens, which enables a number of tricks – by declaring inputs on seperate forms (displayed as seperate screens) with the same name attribute, you can make sure they always mirror each other’s values.  If for any reason you don’t want this behaviour for some fields, you can declare an onBlur event and remove them from the store.

Option Lists

I needed a form screen which listed a number of fields which could be changes, such as railcard type in the screenshot below, and by tapping on the field the user would move to a list of all the possible options from which they could select one.  A few examples of this UI pattern from my iPod Touch Settings app are:

  • Settings > Music > Audiobook Speed (list of 3 options)
  • Settings > Video > Start Playing (list of 2 options)
  • Settings > Safari > Accept Cookies

Visually, it looks like this:

iPhone option selection UI widget

I implemented in two stages. Firstly, I generated CSS to render a radio input (with label) as a block with the tick if it is selected, using a bit of custom Safari CSS (-khtml-appearance:none;) to suppress the native style of a checkbox – which interestingly changes from relatively nice on an iPod Touch v2 to quite nasty on an iPhone 3GS.

Next up, I tried to think of a natural way to express the options in HTML, and ended up with the idea of getting a script to rewrite any select in a form which has the CSS class of ‘panel’ into a seperate linked panel.  The markup you write looks like this:

<div class="row">
 <label for="buy_railcard">Railcard</label>
 <select id="buy_railcard" name="railcard" class="panel">
  <option value="rc_none" selected>None</option>
  <option value="rc_youth">Youth</option>
  <option value="rc_family">Family</option>
  <option value="rc_senior">Senior</option>
  <option value="rc_disabled">Disabled</option>
  <option value="rc_network">Network</option>
  <option value="rc_hm">HM Services</option>
 </select>
</div>

By default, it would render like this (taken from desktop Safari, just to make my life easier):

Selects as they would render in Safari without the script

The script rewrites the above HTML on the original form like this:

<div class="row">
 <a href="#select__buy_railcard">Railcard
  <input type="hidden" name="railcard" value="rc_none"/>
  <var id="railcard-rc_none" class="_lookup rc_none">None</var>
 </a>
</div>

Points to note:

  • The original form will submit in exactly the same way to the server
    • the new hidden field within the link has the same name as the select and the value of the selected option.
  • The textual label of the selected option is copied into the var tag, which actually visually shows the selected option to the user
    • the var is also given the option value as a css class, which allows us to do the funky icons on all labels if we want (using :before generated content, in this case).

The script also creates a new form.panel screen containing the options as a radio group, like this:

<form id="select__buy_railcard" class="panel" title="Railcard">
 <fieldset class="radiogroup">
  <div class="row">
   <label class="rc_none" for="buy_railcard_option_rc_none">None
    <input id="buy_railcard_option_rc_none" type="radio" value="rc_none" name="railcard"/>
   </label>
  </div>
  <div class="row">
   <label class="rc_youth" for="buy_railcard_option_rc_youth">Youth
    <input id="buy_railcard_option_rc_youth" type="radio" value="rc_youth" name="railcard"/>
   </label>
  </div>
  <div class="row">
   <label class="rc_family" for="buy_railcard_option_rc_family">Family
    <input id="buy_railcard_option_rc_family" type="radio" value="rc_family" name="railcard"/>
   </label>
  </div>
  <div class="row">
   <label class="rc_senior" for="buy_railcard_option_rc_senior">Senior
    <input id="buy_railcard_option_rc_senior" type="radio" value="rc_senior" name="railcard"/>
   </label>
  </div>
  <div class="row">
   <label class="rc_disabled" for="buy_railcard_option_rc_disabled">Disabled
    <input id="buy_railcard_option_rc_disabled" type="radio" value="rc_disabled" name="railcard"/>
   </label>
  </div>
  <div class="row">
   <label class="rc_network" for="buy_railcard_option_rc_network">Network
    <input id="buy_railcard_option_rc_network" type="radio" value="rc_network" name="railcard"/>
   </label>
  </div>
  <div class="row">
   <label class="rc_hm" for="buy_railcard_option_rc_hm">HM Services
    <input id="buy_railcard_option_rc_hm" type="radio" value="rc_hm" name="railcard"/>
   </label>
  </div>
  </fieldset>
</form>

Date Selection

One of the greatest things in HTML 5, to me, is also one of the simplest – the input tag has now been extended to allow all sorts of new types, such as dates, telephone numbers and even colours. The idea is that browsers will then handle these specially with funky calendar drop downs etc that curretly have to be implemented in Javascript – and on mobiles, they can use a more appropriate native solution optimised for the keypad, with address book access etc.

Obviously, no mobile browser has bothered to implement these – today you’ll have to look at Opera desktop if you want to see a browser starting to do it correctly.

In the absence of a native widget, I implemented a date selector myself.  On the iPhone itself, this is implemented in a style similar to HTML drop-downs in Safari – difficult to achieve in HTML alone, and not actually that natural for selecting travel dates.  I opted to support date selection with a calendar reminiscent of theiPhone calendar app’s instead:

Date selection with iUI extension

As before, this is implemented with a standard piece of HTML that is rewritten by the script.  To add a calendar you add an input like this to your form:

<div class="row">
 <label for="buy_travelDate">Outbound Date</label>
 <input name="travelDate" id="buy_travelDate" type="date" class="date" value="1/1/2009">
</div>

The type you choose to assign can be either date or text.  If you set the input’s type to text by hand, the script will always replace it with a custom calendar.  Currently, Safari rewrites any type it doesn’t understand to text when the page loads; if and when date support is added, this will presumably cease and the script will stop handling dates for you and leave selection to the browser.  Your choice which you want!

When the form is first loaded, your markujp is rewritten like this:

<div class="row">
 <a href="#select__buy_journeytype">Journey Type
  <input type="hidden" name="journeytype" value="tt_single"/>
  <var id="journeytype-tt_single" class="_lookup tt_single">Single</var>
 </a>
</div>

There will also be a (singleton) extra screen created for the date picker like this:

<form id="_datepicker" class="panel">
 <p>
  <span id="_dpback" class="back"> </span>
  <span id="_dpmonth" class="month"/>
  <input id="_dphidden" type="hidden"/>
  <span id="_dpfwd" class="fwd"> </span>
 </p>
 <table id="_dptable" cellspacing="0" cellpadding="0" border="0">
  <colgroup>
   <col class="sun"/>
   <col class="mon"/>
   <col class="tue"/>
   <col class="wed"/>
   <col class="thu"/>
   <col class="fri"/>
   <col class="sat"/>
  </colgroup>
  <thead>
   <tr class="days">
    <th>Sun</th>
    <th>Mon</th>
    <th>Tue</th>
    <th>Wed</th>
    <th>Thu</th>
    <th>Fri</th>
    <th>Sat</th>
   </tr>
  </thead>
  <tbody>
   <tr class="wk1">
    <td> </td>
    <!-- etc -->
   </tr>
   <tr class="wk2">...</tr>
   <tr class="wk3">...</tr>
   <tr class="wk4">...</tr>
   <tr class="wk5">...</tr>
   <tr class="wk6">...</tr>
  </tbody>
 </table>
</form>

The screen is a singleton, which means it will only be created once, and reused for every date picker in your app (which saves on memory).  Month and day names are taken from arrays which could be externalised and internationalised easily if required (CSS class names on cols are hardcoded though).

Every time the date picker is selected, the script refreshes the calendar, working out the date from the hidden field on the original form and copying over the relevant details.  Table cell contents are updated with the relevant date, and onClick events set to make selections work.

There are a few options, which can be passed in using CSS classes applied to the date field:

  1. If the today class is specified, then any selection of today’s date will be stored on the form (and shown visually) as ‘Today’ instead of the date;
  2. If the future class is specified, only today and future dates are visible and selectable;
  3. If the past class is specified, only today and past dates are visible and selectable;
  4. A date pattern can be specified using the following syntax:
    • Parts of the date:
      • d for the date eg. 28
      • D for the day’s abbreviated name eg. Mon or Fri
      • m for the month’s number eg. 1 (for January)
      • M for the month’s abbreviated name eg. Jan or Dec
      • y for the year as two digits eg. 09
      • Y for the year as four digits eg. 2009
    • Other symbols:
      • _ underscore is converted to a space
      • c is converted to a comma
      • Hyphens and slashes are also allowed.
    • Examples:
      • d/m/y goes to 3/8/09
      • d-M-y goes to 3-Aug-09
      • Dc_d_M_Y goes to Mon, 3 Aug 2009

If a date format is set, then only that format can be used to specify the value of the field.

That’s basically it for my extensions – having documented them, I’ll now see if anyone wants them merged in to the main iUI framework!