The Daydream Blog

Archive for the ‘Development’ Category

MacMacDev

Wednesday, May 21st, 2008

I had the great privilege to meet a number of Scottish based Mac software developers at the first Edinburgh MacMacDev meeting. The group was set up by head Cocoa cheer leader, David Masters of PyrusMalus. there have been a couple of meetings so far in Glasgow and one in Edinburgh.

Since moving to Scotland 18 months ago, I have been surprised by the number of Mac developers based here. I had heard of the Silicon Glen, the idea that there are a number of tech related companies in Scotland, but it was a great surprise to find so many Mac developers here. It makes a huge difference to have a local community, as well as a strong online one.

Glasgow meetings are planned for the 4th / last Thursday of every month, with the next one on 29th May.

Edinburgh meetings are planned for the 2nd Thursday of every month, with the next meeting planned for June 12th. Whilst this is during Apple’s developer conference, WWDC, there should still be a good attendance. Exact venue is yet to be confirmed, and the best place to keep an eye on things is the MacMacDev Website

There are also plans afoot to have a MacMacDev meet up at WWDC, details yet to be confirmed, which will be a good opportunity of East and West coasters to meet up to compare notes.

Differencia: Code Acknowledgements

Sunday, November 18th, 2007

One great thing about being a Mac developer at the moment, is that there is a lot of free-to-use, free-to-distribute software that helps you do common things that Apple’s developer frameworks oddly do not provide. So there is quite a lot of third party code in Differencia. The developers are largely unaware of the use of their work in Differencia, or in many other products. I would like to say a big Thankyou to all of those developers whose work has unwittingly gone into Differencia. As well as nestling credits in the About Box, I would like to thank them again here:

Ken Ferry

KFSplitView

Matt Gemmell

NSColor+ContrastingLabelExtensions

TunesWindow

Chris Hanson

BDAlias

Daniel Jakult, Red Sweater Software

NSTableView+RSAutosaving

Andy Matuschak

AMRollOverButton

Help Toolkit

Andy Matuschak / Tom Harrington

Sparkle+

Sean Patrick O’Brien

iLifeControls

Jordy Rose, Belkadan Software

GenericToolbar

Shiira Project

HMBlkAppKit

Chad Weider

CTGradient

Thanks to all of them and I hope that I can contribute back to the Mac developer community in the same way in the not so distant future.

Suicidal Code Redux

Wednesday, October 24th, 2007

Back in July, Daniel Jakult posted some sample code for some suicidal code that prevents your application from running beyond a fixed period after it was compiled. Ideal for a Beta copies of your software that you don’t want used beyond a certain period, without having to deal with licences. For example the Beta release of Differencia that was released last week.

In the comments for Daniel’s post it was pointed out that the sample code was not internationalised and might cause an issue when run outside of English speaking countries. Of the suggested solutions in the comments, one, I suspect, exhibits the same issue and the other is very complex.

I discussed a potential solution with Michal Bencur (benko23) in the #macsb IRC channel a couple of weeks ago and I’ve posted some sample code to resolve the locale issue below.

The gcc documentation states that __DATE__ is in the format “MMM dd yyyy”, but I have no idea whether gcc will localise this when compiling in non English locales, but if it does, just replace “en_US” with the locale you are using when compiling.

The code is also Tiger only, as it uses a 10_4 behaviour date formatter for proper locale handling.

// Based on original code by Daniel Jakult, based on an idea from Brian Cooke.
#ifdef BETA  // 4 week expiration
#define EXPIREAFTERDAYS 28
#endif

#if EXPIREAFTERDAYS
NSString* compileDateString = [NSString stringWithUTF8String:__DATE__];
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setFormatterBehavior:NSDateFormatterBehavior10_4];
[dateFormatter setLocale:[[[NSLocale alloc] initWithLocaleIdentifier:@"en_US"]
	autorelease]];
[dateFormatter setDateFormat:@"MMM dd yyyy"];
NSDate *compileDate = [dateFormatter dateFromString:compileDateString];
[dateFormatter release];
NSDate *expireDate = [compileDate addTimeInterval:(60*60*24* EXPIREAFTERDAYS)];

if ([expireDate earlierDate:[NSDate date]] == expireDate)
{
	// Run an alert or whatever

	// Quit!
	[NSApp terminate:self];
}
#endif

iPhone SDK: Woops

Friday, October 19th, 2007

Earlier in the week I suggested that developers should get over the lack of a “proper” iPhone SDK. Looking at Apple’s Web Apps directory, I felt that a lot of developers were getting on with things.

Of course the next day, Apple announced that there would be a proper iPhone SDK in Feb. This does highlight Apple’s hubris at claiming that Web tools were a full SDK as I had previously claimed.

More importantly along with the iTunes Plus price reductions, it does appear that Apple is responding to the wave of criticism that has come its way over the last few months. With a bit of luck, Apple will also open up iPhone ring tones as part of that response.

Back the the iPhone SDK, my biggest concern is that I will fall into the same trap I did with my previous smart phone. Installing all manner of “cool” apps that I never use and which clutter up the limited resources on my phone. When I get an iPhone, I’ll be interested to see whether I prefer using web based tools to full blown, native, apps. Of the shareware that I currently use on my Mac, a GTD solution is the only app that I feel that I would want on my iPhone. Of course I’d happily do without the YouTube and Stocks apps as well.

iPhone SDK: Get Over It

Monday, October 15th, 2007

Whilst many Mac developers have bemoaned the lack of a “proper” iPhone SDK, it appears that the web developers have wondered what all the fuss was about and just got on with it. Apple has created an online directory of iPhone optimised web apps, which has grown to over 200 hundred entries, in less than a week. Perhaps we Mac developers need to be less afraid of change. We petulantly worried about Carbon vs. Cocoa before realising there was a place for both in the same app. So perhaps we need to accept web development as part of our necessary armoury of tools, for OS X development beyond the Mac.

Presenting web tools as a “proper” iPhone SDK was patronising to developers at WWDC ’07, and symptomatic of Apple’s “Year of Hubris”. But developers need to accept that this is the reality of the situation. We also need to accept that iPhone updates will delete third party hacks, close loop holes and possibly render the phones inoperable.

The iPhone Elite Team have released a way to unlock “bricked” iPhones, having accepted the reality of the situation. John Gruber has it completely correct when he says that there is a “misguided mindset” in thinking Apple “screwed them over” with the 1.1.1 update.

As a developer, if you want to bring your app to the iPhone, you either need to add web development to your tool-chest or get involved in the hacking process. However, making money out of that app on the iPhone maybe a tricky business model.

My prediction is that, as with iPod games, there will be a coterie of developers who will be allowed to bring Apple sanctioned apps to the iPhone and iPod Touch, delivered through the iTunes Store.

Debugging a 75 year old

Tuesday, July 31st, 2007

My father has been a computer user since the early 1980′s and a Mac user for about 2 years. Recently he sent me the following support email:

How to access CDROM ?

Yesterday one disc automatically came out – I pushed it back and it seems to have dropped deep inside the computer 

My father uses an iMac G5 with a slot loading CD drive. My initial reaction was amazement that he had gone 2 years without hitting this problem before. It reminded my of a number of issues that he has had over the years that have always been quite fascinating to resolve. My father is an intelligent 75 year old man who can do things with Excel that make my head hurt. Yet there are things that I find easy, “intuitive”, that he has problems with. 

PEBKAC

When IT people handle support requests, a lot of the issues are put down to PEBKAC – Problem Exists Between Keyboard And Chair. In other words it is too easy to assume users are not computer literate or are just plain stupid. Once, our brightest user phoned up saying he could not log in to our system and it turned out he had left the CAPS LOCK on. If our most intelligent users can fall prey to such simple mistakes, PEBKAC cannot be the issue. Apple and Microsoft have both tackled the Caps Lock key issue, which shows how these issues can actually be resolved by better user interaction design.

At Apple’s developer conference, John Geleynse, Apple’s User Experience Evangelist, always gives a talk on user interface design. Year after year he presses home the need to understand the user’s “Mental Model”. But this issue goes beyond even the topics John covers in his annual sessions.

My father mentioned that he was used to a physical eject key on the CD-ROM drive. I realised that the Mac’s solution is pretty poor as both the software button in the Finder and the button on the keyboard, whilst easy to access, are both located quite far away from the actual drive. This is a failure to apply the Proximity principle of good design. Of course the current method is still far more sensible than dragging the disk to the Trash.

He also complained that his address labels were no longer printing out correctly and in this case he had in fact been using different sized labels. What was fascinating was the Excel spreadsheet that he used to print his labels. He had adjusted row heights and column widths to represent each label and surrounded each label cell with narrow cells as margins. It was clearly a painstaking effort on his part. I was about to adjust his spreadsheet for the labels he was now using, when he opened up another one that worked perfectly. I considered telling him about Word Label Printing in combination with Mail Merge but concluded he would be more comfortable with the solution he was familiar with.

Again I have often come across intelligent users who have come up with cunning, but fragile, solutions where full solutions already exist. They were unaware of these solutions, that may well have been intuitive and easy to use, but their actual existence was not obvious.

Conclusion

These issues highlight that the problem is not stupid users but stupid user interaction design. All too often as developers we marvel at how users do not understand how the application works. Yet the issue is that we are too familiar with the application to appreciate what it feels like to be inexperienced with it. It is precisely those support issues that strike us a stupid that we should examine the most closely for opportunities to improve the user interaction of our applications. The problems do indeed exist between the keyboard and chair but not those of the users but of the developers.

 
Site by Line