Firstly, let me be blunt here: the current state of storing data in Ubiquity commands is a mess. There are several APIs, several places to put the data, and several thoughts on how it should be done. And to me, none of them are adequate. To a certain extent, the same applies for addons, when it comes to sharable data.
And this isn’t just a coding problem: it also directly affects the user. Not only are there several methods of asking the user for information, but the information is fragmented in the system, so its not uncommon to need to fill in the same information more than once.
Lets tackle the user-facing issues first, in true Ubiquity fashion. This will be Part 1 in a mini-series of blog posts on this topic. Part 2 will focus on the developer’s side of the issue. So lets get started.
Data vs Information
One part of this problem is that some commands want data entered, some request information, while others use knowledge. You can read about the differences between these concepts here. To summarize and bring that into context: data is what the code deals with, and it should stay there exclusively. People don’t think in data, but in higher levels such as information, knowledge, and wisdom. Thinking in data is difficult – which is in contrast to a computer, where data is the native language and using higher-level constructs is more difficult.
And so we have to choose – do we make ourselves work harder, or do we make our computers work harder? Hopefully the obvious answer is the later option.
A simple example of this difference is entering a date/time. Ubiquity uses the awesome date.js library for this. It allows you to say “next Thursday”, as opposed to figuring out what date next Thursday is, and then figuring out what format is expected. Neither of those tasks are trivial. Sure, you may be used to doing it and maybe even be able to do it quickly, but its still a lot more work than just “next Thursday”.
Unfortunately, its not uncommon to be asked to enter the same information more than once. This isn’t just a problem with Ubiquity, but with computers in general. Since information/preferences/data is stored in various different methods/locations/formats, its next to impossible to consolidate it system-wide. But the problem can at least be made to not get worse within (at the very least) Ubiquity.
Part of this can be solved by going back to the data vs information problem. When data is stored, it can take on many different meanings, since its meaning is dependent on the code that uses it. But if information is stored, then although the use may vary, the meaning behind it is global.
As an example, lets look at what’s required to login to a web service. The user generally has to supply at least 2 pieces of information: a login name, and a password. But where’s it stored? In the password manager? In the preferences? Which URL should be used as a key? The front-page URL? The login-page URL? The mobile version’s URL? The web service API’s URL? What about automatic logins, so the user doesn’t have to confirm every time – if the user has more than one login for that web page, how is it decided which one should be used?
A lot of the above issues (if not all of them) can be solved by reducing fragmentation, and storing information and knowledge rather than data. Picture this: Instead of associating login information with a specific URL, its associated with a uniquely identifiable name of the web service. Then each URL that is trusted to be associated with that web service is associated with the web service’s name, and this association is automatically discoverable (and verifiable) without user input. Finally, all of this information is stored in such a way that its just as easily accessible to the browser, extensions, Ubiquity commands, local applications, and the user – on all of their computing devices.
Now instead of storing fragmented data, we have consolidated information and knowledge.
To finish off Part 1, I’m going to describe the user-facing component of a solution. Part 2 will cover the technical details, including an API.
If you’ve used a Ubiquity command that requires user input or some form of configuration, you would have no doubt noticed that the command has to provide its own method of presenting this task to the user. This invariably leads to multiple “setup” type commands – one for each command that needs user configuration. On top of that, these setup commands themselves are inconsistent – different naming schemes, different way of entering the same types of information. For instance, do you use separate setup commands for your login name and password, or enter them both in the same command? If its the same command, what happens when you change your password? I think the only thing these setup commands have in common is that they’re annoying to use.
But what if all you needed to do was tell Ubiquity “my twitter login is theunfocused“. Or “my home is Dunedin, New Zealand“. Or “my google apps domain is blairsawesomewebsite.co.nz“. Simple, yes? But what if you want different information to be used for different commands? Say you wish to use the “mozillaubiquity” twitter account when using the “twitter-timeline” command. Simple: “my twitter login for twitter-timeline is mozillaubiquity”.
That’s it for Part 1. As mentioned earlier, Part 2 will focus on the technical details and an API. Comments are not only welcomed, but wanted!