I wonder if Tim Berners-Lee got his idea for the semantic web while reading Gary Larson’s The Far Side comics:
Apr 22 2010
Want iPad multitasking? Buy multiple iPads.
A while ago I suggested on Twitter that the solution to iPad’s lack of multitasking is buying multiple iPads. People thought I was joking. When I shared the same idea with my coworkers they didn’t take me seriously either. Then a couple of weeks ago I came across an interesting piece in Newsweek in which the Fake Steve Jobs interviews the real Steve Wozniak. The interview itself is about what The Woz thinks of the iPad but it ends with the following gem on multitasking:
Wozniak: …By the way, I solved the problem of battery life and [the lack of] multitasking on the iPhone.
Interviewer: Really?
Wozniak: Yeah. I just have two iPhones, so if the battery runs down on the first one, I can use the other. And if I’m talking on one, I can use the other one to look something up. You would not believe how much use I get out of that.
Perhaps my idea wasn’t so far-fetched after all.
Sure, ditching your current setup and replacing it with multiple tablet computers would mean quite a change in how you use your computer. But many people would likely be perfectly happy with the alternative. Like those people, for example, who are ordering iPads faster than Apple can manufacture them.
With iPads having neither a keyboard nor a mouse and being small enough so that you can have several of them in front of you, I imagine switching between them should be a snap. Also, the added screen real estate of what is essentially a multi-monitor setup should also make it easier to work with multiple apps at the same time.
Of course, this idea is not new at all. You may have even seen it on TV decades ago. A user called derefr left the following comment over at HackerNews when I mentioned my idea:
[Using multiple iPads] makes complete sense to me—remember the scenes in Star Trek where someone is sitting at a desk absolutely covered in PADDs, each doing one little thing? We just need to wait for the price to come down :)
Being located in Europe, coming across even one, let alone two or three iPads has proven to be a bit difficult for me. So if someone reading this has had the chance to try working with more than one iPad at the same time it would be great to hear how well it works and what problems you’ve run into.
Comments Off
Nov 10 2009
Don’t — in Scala
While browsing Reddit yesterday, I came across this thread on Perl’s Acme::Don't module. The Acme::Don't module is a joke module which adds support for “don't“, the opposite of the “do” command. The “don't” construct accepts a block of code and then DOESN’T execute it, no matter what. Now, lately I’ve been playing around with Scala and I know that thanks to its flexible syntax it’s possible to create functions which look and behave just like control structures. This got me thinking… could I implement a useful version of “don't“?
After a couple of minutes I came up with the following 2 use cases (in addition to the original standalone don’t block):
dont { ... }
dont { ... } unless (condition)
dont { ... } until (condition)
Implementing the dont { ... } part is easy. The only thing needed to make this work is a function which accepts a block of code and doesn’t do anything with it.
Adding support for the unles/until part is a bit trickier, but still easy. For this to work, the dont function must return an object which contains methods named unless and until. These methods then evaluate the condition passed to them and execute the original block of code if/when the condition is true.
It’s probably best if I just show you the code:
def dont(code: => Unit) = new DontCommand(code)
class DontCommand(code: => Unit) {
def unless(condition: => Boolean) =
if (condition) code
def until(condition: => Boolean) = {
while (!condition) {}
code
}
}
Now there’s nothing else left but to use it in an example:
/* This will never be executed */
dont {
println("Hello? Can anyone hear me?");
}
/* This will only be executed if the condition is true */
dont {
println("Yep, 2 really is greater than 1.")
} unless (2 > 1)
/* Just a helper function */
var number = 0;
def nextNumber() = {
number += 1
println(number)
number
}
/* This will not be printed until the condition is met. */
dont {
println("Done counting to 5!")
} until (nextNumber() == 5)
Runnig the above code should print:
Yep, 2 really is greater than 1.
1
2
3
4
5
Done counting to 5!
Nov 08 2009
Predictions on the future of NoSQL
These days new NoSQL databases are springing up faster than URL shorteners. Even incomplete lists are likely to mention over 50 of them, most of them never heard of before. But even though they’re all being lumped together under the same name, they are so different from each other that there’s still a dilemma how to come up with a name which would describe them for what they are instead of describing them for what they’re not.
Nobody knows for sure what the future of NoSQL will be like, which way the development is most likely to head and who the winners will be, but we can still try and make some predictions. Here are mine:
Several subgroups will emerge
This is not as much a prediction as much as it is an observation of already visible patterns. At least two main groups will emerge from the NoSQL movement: networked data structure servers (key/value stores, queues, …) and databases for working with structured data.
The data structure branch will remain very diverse
Typical software in this category is rather minimalistic, both in terms of functionality and in terms of code size. Thanks to this the threshold for entry of new players is rather low; also low is the price paid by users for switching between competing implementations.
Various players will likely specialize in some technological niche and they will continue to be used mainly as means of speeding up applications and not as fundamental building blocks.
Relational databases will fight back
Some databases already have support for storing, manipulating and indexing structured data in the form of XML. I have a feeling that JSON support can’t be far away. For most users this will be enough to stay with the established players in the database field instead of choosing a strictly document oriented database.
Document oriented databases will morph into graph databases
Implementing cross document referencing will take them half way there. Pressure from the relational databases, as described above, will push them the rest of the way.
SPARQL will become the query language of choice
SPARQL is a query language for RDF1; in other words: a language for querying graphs. It supports querying multiple data sources at the same time (federated queries) and there are projects underway to make it work with Hadoop clusters.
I’m not saying that alternative methods of querying will disappear completely! I’m just trying to say that the key players most likely to be used by the average developer (the next generation graph database equivalents of MySQL and PostgreSQL and similar) will end up standardizing on SPARQL instead of inventing yet another language.
Software will gain weight
Reading about NoSQL databases gives me a feeling of deja-vu. Most of it reads almost exactly like articles about MySQL from the beginning of this decade: “We’re better than competition because we don’t have transactions/triggers/datatype checking/guaranteed consistency/fulltext search/…”. MySQL now has all of those features and NoSQL databases will follow in the same path. Most users will start hitting walls due to lack of features, not due to performance issues and when that happens having features will become more important than being lean.
The cycle will repeat itself
After a decade or so a new class of players claiming that their lack of features is their strength will emerge once again
- RDF is an extremely simple format wrapped in a metric buttload of mystery in misunderstanding. But more about that some other time. ↩
Sep 15 2009
Replacing menus with dashboards
Is it just me, or do most dialogs on Android seem to be removed really, really far away from the main parts of applications?
Not sure what I’m talking about?
Let’s take a look at the browser, for example. Just entering a new URL requires you to go through 3 different screens:
By the time you can start typing it feels like you’re already in a different application1. Switching to a different window also involves going to a special part of the application designed to handle this single task.
This pattern is not limited just to the browser. Entering an address in the maps application or searching the list of your contacts also involves going through several steps.
Back to the browser…
If you take a look the UI of a regular browser you can immediately see a number of frequently used elements such as the location bar, the back button and tabs for switching between windows. Those UI elements are always visible and usable with a single click. On mobile devices things are a bit different. Because of limited screen sizes most of browser’s UI is either eating away precious screen real estate (like on the iPhone) or is hidden behind a menu button (like on Android).
Except that because of the nature of menus, many of those features are not hidden just behind the menu button, but also behind an item on that menu.
Now, just as I’m typing this, Marissa Mayer is on the stage at TechCrunch50 introducing Google fast flip and talking about how Google is obsessed with speed and shaving milliseconds off of repetitive interactions. So what can can we do to speed up interaction with Google’s mobile browser?
First, we need to understand what’s wrong with menus.
A typical menu is a list of actions available for that application, but most of those actions can’t be performed from the menu itself. Instead, selecting an item takes you somewhere else where that action can finally be performed. In essence, a menu keeps asking the question “What do you want to do?” over and over again and the user then needs to explicitly say that he wants to go to to the place where he can type in an URL or go to the place where he can switch to a different window, etc.
How do we handle this situation where we know that in many applications the user’s answer to the menu’s question is going to be the same most of the time?
Like it is the case usually these days, the solution can already be found on the iPhone. No real surprise there. The iPhone doesn’t have built-in support for application menus which could be copied, but it does have this:
What you’re looking at is a special dashboard for controlling music playback, which can be brought up by pressing the home button twice.
With a bit of bad luck – or bad judgment – this could have easily been implemented as a list of items such as “adjust volume” and “control playback”, with each of them leading to a new screen where that action could be performed. But instead its designers made it possible to perform common actions directly from the pop-up and added a “Music” button that takes you to that other app where the rest of the playback controls are.
So let’s take this dashboard pattern and apply it to Android’s browser menu:
While some features (like bookmarks) still remain hidden behind a menu button, the two most commonly used ones are immediately presented in usable form. The “go” button is replaced by an actual location bar and the “Windows” button is replaced by thumbnails of windows. You now no longer need to announce first that you want to go to a different page or switch to a different tab; you can perform that action directly instead.
A quick before/after comparison:
| Action | Before | After |
| Loading a web page | press “menu” → press “go” → focus URL field (3 steps) | press “menu” → focus URL field (2 steps) |
| Switching to a different window | press “menu” → press “tabs” → select tab (3 steps) | press “menu” → select tab (2 steps) |
Removing a single step here and there may not seem like much, but it adds up. Making a typo in the URL or working with several windows suddenly becomes just a little bit less frustrating. A simple improvement that can be achieved simply by ignoring the established meaning of the word “menu”.
- Sure, if you have a phone with a physical keyboard you can just start typing and invoke the default action without going through menus, but what if your phone uses an onscreen keyboard or if you want to use some other action? ↩
Jul 04 2009
Advertising overload
I followed a link to Forbes today and this is what I saw:
There’s an article hidden somewhere in that screenshot. Can you find it?
Content is no longer king. It is now a third-rate citizen; a stinky bait used to lure in visitors; a parasite eating away at precious advertising space.
Next Page »
