Posts tagged: GUI

Thoughts on the (iTablet) iPad – connectivity, apps, multitasking, integrating with Macs

The following is a draft I wrote prior to the announcement of the iPad, but which I didn’t publish because it was a series of hypotheses based on an as yet non-existing product. It’s a series of thoughts on how an interface of a touchscreen larger than an iPhone might look like. It is inspired by both my experiences with Macs and since recently with an iPod Touch. Here goes.

A couple of thoughts I had last night (written on 13.01.2010) about interfaces, the current state of development for the iPhone OS, how Apple could build a hybrid of Mac and iPhone OS, and how the company could build multi-tasking into its rumoured tablet. My thought were the following:

Welcome to the Apple Store - Apple Store (U.S.).jpg

a. A new category: I don’t think the iTablet, if it exists, will be either a Mac or an iPhone. My super-superficial reason: it doesn’t fit in the Mac line-up depicted on the online Apple Store (see pic), but a more underlying reason is that I don’t see space for it in either a Mac-category or a Mobile phone/media player category. Which is not to say that it won’t do either well, but I think it will more fall into the class of Netbooks, though of course with the purpose of bombing those low-tech, low-innovation devices out of the water… just like Apple did with MP3 players and with Phones. Note from today: as it turns out, the iPad is depicted below the iPod, iPhone, and Mac lines, but time will tell where it will be once it’s on sale.

b. The Keyboard: I think that any 10″ screen will demand more connectivity to secondary (Apple) devices than the iPhone allows for. That means, an external keyboard and mouse, which transforms the tablet into a desktop. I have less complaints about the software-keyboard now, after working with a Touch for a while, but I still don’t see it as an alternative for longer texts, which a larger screen would warrant. Some months ago, I made a stupid mock-up of the iPhone + a keyboard (see pic), which is how I envision it looking (only better).

c. The App Store: 3 Billion Apps downloaded, Apple just reported, which also suggests a kind of lock-in. For better or worse, developers have accepted the App-store and I think it works for several reasons for both, namely more protection from pirates, more predictability for developers when developing for the black hole that is Apple, and more control by Apple, which is what Apple likes, not to mention new income streams for both. I think the App Store will continue to exist and will present new challenges when talking about a larger screen. Note from today: I don’t believe that what we will get to see in less than two months will be that what people were playing around with after the Apple keynote. iPhone apps inflated to a larger screen, come on?

d: The User Interface: I’ve written previously about Quick Look in Snow Leopard and how I also dug its slight innovation in terms of in-icon playing of media. Previously, OS X also introduced Dashboard into Tiger (I believe), whose interface, on the surface at least, resembles the iPhone. My view is that Apple will give developers the option to just keep the same resolution apps as they have offered before, though not exclusively of course. But imagine “Quick Looking” an app and still having it run inside its “Icon,” while the user does something else. For the rest, I of course think that full-screen Apps will exist, which is where Dashboard comes in, or at least a type of Dashboard. (Note: that was wrong. More below.)

Apple Dashboard in iPad-1.jpge. Integration with the Mac: One of the most underused interfaces, at least on my Mac, is Dashboard, which allows people to have continuously open widgets on anything from news, to games, to radio, to system monitoring. It’s useful for those purposes, but not really something i spend more than a few minutes at a time with. Yet the first thing that came to mind when thinking of a “Tablet,” using both iPhone and Mac interface components, was Dashboard. It creates a new layer on top of a traditional desktop, allowing for user-input and information display. When I envision someone running the apps that would work on the “iTablet” also, I think of it either being that you open up a new layer on your Mac and run the very same apps on it through something like a Dashboard-like interface. Or, and the simplest solution is usually the best, through having the Tablet sync through iTunes with regular applications on the Mac.

Note from today: well, obviously this was wrong, but there have been several theories aired of having a type of Dashboard on the iPad for apps like calculator and weather, which don’t at all make sense to run in single focus on a larger screen than the iPhone.

Further thoughts from today: I do think that we will see a new OS update for both the iPhone and iPad before the release of the iPad. This will address the concerns that people have about it just being a larger iPod Touch. For the rest, to me the only downside to this device is the lack of a front-facing camera for video-calling, and some minor things. And I also think it’s the perfect “parent device!” What the Wii was to gaming, the iPad is to computing, addressing a very very blue ocean.

As previously stated, I’m still in line to get one this year, though only after trying one first.

Vincent

OS X: Apps & Spaces, you guys haven't really figured it out yet

Dear App-maker and Apple,

I appreciate Spaces a lot as a feature on Leopard. I think it makes me more productive, in the sense that I am now completely focussed on my blog editor in space 2, and all the other distracting apps are stowed away in the other spaces. But Spaces isn’t perfect, which is part Apple’s fault and part Apps’ fault.

Exhibit 1: the preference pane

The Spaces preferences are a mess, one long list of messes. When adding an app to a certain space, it doesn’t go to that app in the list, instead it adds it, I have to search for it, and find it has been set to the latest space I used or assigned an app to (which is a actually good, I’m not a whiner).

Why is all of this centralised? If I want to see what space an app is assigned to, why not have me do that in the app-preferences? To me it makes so much more sense to install an app, go to its preferences or a menu-item, and just set the space from there. Instead of having to dig through the bloated preference pane.

Exhibit 2: the auto-switching

OK, I actually don’t have a problem with selecting an app and having it open in its appropriate space. But what I do have a problem is apps ripping me away from the space I’m in, sometimes multiple times, because… I don’t know, they call for it? This happens with Pages, with Marsedit, with Safari, and I don’t know what. Somehow, when it loads up stuff, like webpages or those pesky floating info-windows, it calls Spaces to attention and poof, I am ripped away from what I was currently doing.

That Sir, is not my definition of a productivity enhancer.

I have now set Spaces to not auto-switch, but what I would really like is for a. this not to happen and for b. to be able to set, per app, which one auto-swicthes and which doesn’t—another case for having Spaces be included in app-preferences.

Exhibit 3: ghost dialogue boxes

Regardless of what app I use, this happens constantly. Dialogue-boxes don’t always open in the same space as the app is in. Instead, a dialogue box opens, I know it does, but I can’t find it. And when I switch between Spaces, I sometimes see it floating by, like a ghost again. Hiding the app in front of it doesn’t work, the dialogue box disappears too. I have to minimise the app(S) in front of it, to find that stupid box. Not effective!

I want dialogue boxes per app to stick to the space they are set to, and preferably stay on top (if anyone knows a hack for the latter, post a comment).

In conclusion…

I assume that most of this is a design error on the part of Apple, but I’d really like for this to be improved. Exhibit 1 is clearly a user-interface issue, which could be drastically improved by allowing preferences to be set per app. Exhibit 2 and 3 are bugs, no more no less, and I hope that Apple gets it together and fixes it.

Approaches to search

approaches to search-1.jpgLooked at two new (for me) search-engines this week, Cuil (pronounced cool) and Keyboardr. Keyboardr is a geek-project and, like Mac’s Quicksilver, is all about navigating via a keyboard. Cuil, which I had heard of before, I was made re-aware of by a recent Stanford entrepreneurial thought leaders podcast, in which its creation and the theory behind it was discussed. I liked the idea of approaching search as a visual placement problem, as that is how humans (in my opinion) often judge information. Still, I didn’t think that Cuil was particularly innovative, from a GUI perspective. Even so, all interesting projects, as is Mahalo—human powered search.

What remains clear is Google will continue to be the thought-leader in this field, not because it is a better search, but because it is so integrated with the web.

What I’m thinking about is how search can be improved to become useful for human beings, rather than search-engine optimised websites, and the key to that seems to me to be presenting information in the right way for the right person.

Take Java tutorials, which I was looking for last week and where my priority was to find a. the right tutorial for my beginner-level and b. be taught by a good teacher. Two elements that matter here are level and quality, of which the first is easy to search for—just insert ‘beginner’—but the latter is currently being solved by Google as follows: the more it is linked too, the better it must be, which also makes sense. But it does ignore an element, discussed in the Stanford podcast, which is that unknown teachers can both be bad, but also exceptionally good.

Education online is different from education offline. The latter, if good, will be very popular, but interested people will run into a physical constraint—only so many students fit in that building. Online education, if good, will also be very popular but not have the same physical constraints, though possibly imposed price-based ones. But since we are talking good old open source Java, let us assume that price is not a factor. If everyone picks the most linked tutorial, which is also of good quality, it means that everyone potentially ends up with the same knowledge. The commoditisation of code.

But how do you produce exceptional Java-coders? These are arguably all people that walked the extra mile, either through inner potential and/or through environmental factors, such as an exceptional teacher. There’s another factor, which is that diversity can also breed innovation, by exposing people to a wide variety of ideas and perspectives, again made possibly by people working with a wide variety of tutors. Still talking Java here, but it could be applied to anything.

Search, in other words, promotes mediocrity, by leading people to pick the most common denominator, the top-result, rather than across the wideband of possible results, made possibly by the widely hyped up “long-tailed” nature of the internet.

And that is one problem that search is currently facing. How this is solved, is possibly a GUI solution, by presenting results in the right way and right variety. It could also be a human solution, such the one used by Mahalo. It could be a user-generated solution, using social-based variables through sites like Facebook, Twitter, FriendFeed, now LinkedIN, and something that Google is also implementing (badly, I hear). It could be a technological solution, something Cuil is also working on… etc. etc.

One thing is certain, that Keyboardr, no matter how geeky and cool, won’t exactly solve this problem :D

Vincent

Staypressed theme by Themocracy