Simply Jonathan

Archive for 2012

Web History 

Permanent location of 'Web History'

A wonderfully done timeline of the history of the Internet. I think it’s a little oddly lacking for the current stuff – a lot of discussions of browser releases in the 90s, but neither Chrome nor Safari’s releases are mentioned, at all. Python (the general purpose language, which I don’t believe anyone uses without some Web-specific framework on top of it for producing Web stuff) is mentioned, so is Perl and PHP. And Ruby on Rails. Also no mention of HTML5, CSS3, WHATWG or other acronyms that are part of pushing the Web forward today.

It is very nice though. On iOS – and, I’m sure, other touch-enabled operating systems – the navigational arrows are replaced with swipe gestures.

Abandon the Tribalism – Racism Is the Issue 

I’m a Chelsea fan. As such, I’m inclined to give Terry the benefit of the doubt. No-one knows what really happened, and these trials haven’t really made any conclusive proof either way.

What is important is that we get rid of racism, in football and anywhere else. If Terry is guilty, he should be punished severely for his behaviour.

App.net’s Developer Incentive Programme 

Whether App.net will succeed will still likely depend on their ability to make people abandon Twitter for it, but as a developer, I like their initiatives in this regard. Acknowledging third party value, and having that be the founding principle, is something I can only believe will lead to great experiences.

Of course, this is only possible because App.net get money from the users directly, no matter what clients they use. Twitter are leaving money on the table by allowing third party apps to not show ads.

Browser Relations 

Permanent location of 'Browser Relations'

Jeremy Keith on Apple’s non-existant developer relations with regards to Safari. I agree wholeheartedly – having an evangelist who isn’t allowed to speak at external conferences seems… odd. (What does she do the rest of the year, when not preparing for WWDC?)

Now might be the right time to push back at Apple, since they claim they’re doing things differently, but this is something that should be done at any time.

iOS 6 Observations

This is by no means a review. For that I refer you to Macworld, Ars Technica or iMore. These are the observations I made. I notice small things, and generally ignore big things. Mind you, my favourite part of iOS 5 was the addition of the en-dash in the keyboard. So, here they are:

  • They put in a ‘kr’ button in the Danish numbers keyboard. It inserts the letters k and r, which for most people would probably be easier to just type. (Same amount of clicks and they’re closer to each other)

  • The maps are certainly prettier than Google’s. As for the use of them, I must admit I never used maps all that much, but from my limited use of them, there seems to be almost no knowledge of Odense, where I live. (Transit missing is OK for me personally, because I never used the ones in the old Maps.)

  • No password required for app updates is great, and it’s mind baffling it’s taken so long for it to appear. Now we just need same behaviour for free apps (though I see more potential problems with that.)

  • Do not disturb is a great concept, somewhat lacking implementation. The ability to set up schedules would be great. (I have very different times for when I want to receive notifications on weekdays and weekends.)

Technology vs. Utility 

Permanent location of 'Technology vs. Utility'

Matt Drance on the iPhone 5 not having NFC, and how that is not really a problem in the world today.

This point is exactly right. Sure, the iPhone 5 could have NFC. It would probably require a thicker design, might impact battery life, but certainly it could be in there. So could a toaster.

Don’t get me wrong: I think the promise of NFC is a good one, one I’m excited to see. But it’s just a prospect for now.

Sometimes Apple push the envelope for this sort of stuff, what with the non-Floppy iMacs and such. But when they do, it’s because they believe it serves a purpose for their customers (or themselves), not to check off a box in a comparison chart. Currently, NFC serves no practical purpose, only the hope that it someday will.

AV Club Interview With Louis C.K. 

Interesting (and lengthy) interview with comedian Louis C.K.

Louis C.K. is an extraordinary comedian, but what I find most fascinating about him is his approach to the things surrounding his comedy. He obviously rose to some prominence with the radically different business model he tried when selling his show Live at the Beacon Theater, an approach they also discuss in the interview, and in general he seems very set on trying to improve comedy, in the way it is produced and watched.

One particular comment I think encapsulates this brilliantly:

I like to give [employees] a little more than they want, and I like to ask [viewers] for a little less than they’re willing to give.

A Better Model for Locking Devices

This post will talk about my iPhone, iPad, and Macbook specifically, but I am sure that the lessons here are applicable to comparable non-Apple manufactured devices.

The topic is of locking. On the iPhone and the iPad it is done by tapping the small lock-button on the top of the device. (Or, on the iPad, if it has a Smart Cover, by folding the smart cover over.) On the Macbook it is done by closing the lid.

All of these devices, however, have an additional lock mechanism, an automatic one: if the device hasn’t been used for a period of time, it will simply lock itself, thus saving battery by turning off the screen.

So all devices have a manual and an automatic way of locking down. Yet, despite these being conceptually quite different – one active, the other distinctly inactive – they are treated the same when devices wake up.

Whether I lock my iPhone or let it go to sleep, I have to enter the lock-code when I want it to wake up again. Yes, the lock-code can be disabled, or I can set a delay before the device will require the code, but it still applies to both methods of going to sleep.

The thing is, I see these two sleeping methods coming from very different places: when I press the lock button on the iOS device, or when I close the lid on my Macbook, I make a very conscious (and active) choice of not wanting to use the device for the foreseeable future; when I let the device lock up by itself by not inputting into it, I might have forgotten about it, or I might be occupied for a longer time than I had expected with something. I might even just be paying attention to something, waiting to interact with the device for just a short while. (Specific use case illustrating this: When I was at university, I attended quite a lot of lectures where I kept either WriteRoom on the Macbook open, or Plaintext on the iPad. Sometimes the lecturer will take her time to get to the point, or simply not make a point for a while, which means I don’t do anything when the device, but I still want to be able to write something when an idea comes to mind.)

The current situation has me reaching for tools such as the very useful Caffeine to prevent my Macbook from going to sleep. (I don’t believe a similar tool would be possible on iOS.) This introduces another problem: I often forget to turn it off afterwards, which means that if I leave my machine, it won’t turn off the screen, thus wasting power.

I really think all devices could benefit from a realisation of the fact that these are different things, occur for different reasons, and should be handled differently. I even think the change could be made very simply, by adding an unobtrusive checkbox asking whether the passcode should only apply on non-auto-lock (or active lock, or whatever one might choose to call it). On iOS it would most likely require a merger of the Auto-Lock and Passcode Lock panes, but I can’t see any reason for them not being in the same one already.

Light Table 

Permanent location of 'Light Table'

A Kickstarter project (of course) proposed by Chris Granger, which is a radically new editor (inspired by Bret Victor‘s principle from his much-praised talk Inventing on Principle). If this project is funded, and it’s looking good, the resulting product could revolutionise the way we develop software, and make it much better.

PHP: a Fractal of Bad Design 

Over five years ago (phew), I wrote What I don’t like about PHP. This is like that, only infinitely more detailed. (Including a lot of oddities that I knew about, but hadn’t considered serious flaws.)

(Via Marco, who concedes that PHP does suck.)

This is Simply Jonathan, a blog written by Jonathan Holst. It's mostly about technical topics (and mainly the Web at that), but an occasional post on clothing, sports, and general personal life topics can be found.

Jonathan Holst is a programmer, language enthusiast, sports fan, and appreciator of good design, living in Copenhagen, Denmark, Europe. He is also someone pretentious enough to call himself the 'author' of a blog. And talk about himself in the third person.