-
typography: At the GNOME Boston Summit, Owen gave an excellent talk about the parallels between typography and gui design. He made the point that a lot of the rules and conventions that typographers have are generally applicable to ui design. Typography as a field has had 500 years of trial and error to determine many of their principles. Computer interfaces have had only twenty or so. We are missing a lot of the vocabulary needed to describe various conventions and interface elements. Inspired by this, I went out and bought a copy of “Elements of Typographical Style”.
This is an impressive book. I am thoroughly enjoying reading it, and am learning a huge amount. It gives rules (and more importantly, rationales!) to many of the things I do when desigining a dialog.
It also raises the issue of what the important elements of an interface actually are. Consider an error dialog. It has a primary text message, a secondary message, an icon, and some buttons. It may also have extra details. Good error dialogs will also provide a way to fix the issue. This is crying out for some form of ‘logical’ markup, along the lines of docbook or latex, or even gtk_message_dialog_new (parent, flags, type, buttons, message);
This approach breaks down the moment the interface gets sufficiently complicated. Every UI I’ve seen that tries to automate it’s UI has looked dreadful, and has been pain to deal with over the long run. Still, there are plenty of elements that exist on a larger scale than the current widget level. That seems to me to be the next place we should be looking into. I’d like to spend some time adding a set of ‘style sheets’ to the GNOME hig. I’m hoping to have a week or so to dedicate to this at the end of the month.
-
War Craft 3: Sucking away my life and my time. I can feel it… Weirdly enough, you start out playing a bad guy.
-
bookworm: I tried to work on bookworm again. I ran into problems serializing data, and creating new objects. My beautiful (and copied from Elliot) Library.py model is breaking down a bit. I can’t really create a new row in a table and then fill it — I have to insert some of the data simultaneously at creation time. This is a pain, as I’d hoped to be able to do:
obj = library.create_object (‘Library.book’) obj.name = ‘Pride and Prejudice’
I will have to do:
obj = library.create_object (‘Library.book’, name=’Pride and Prejudice’)
While this is shorter, I may not know all the information at creation time.
Additionally, there’s no way to nest transactions (not too surprisingly) in postgresql. I would like to do:
library.begin_transaction () obj = library.create_object (‘Library.book’, name=’Pride and Prejudice’) library.begin_transaction () obj2 = library.create_object (‘Library.person, name=’Jane Austne’) # whoops library.revert_transaction ()
library.begin_transaction () obj2 = library.create_object (‘Library.person, name=’Jane Austen’) library.commit_transaction ()
obj1.author = obj2 library.commit_transaction ()
Will spend tomorrow thinking how best to do this. Elliot does it by serializing his transactions, and committing them all at once. He doesn’t need to access his information in the middle though, which lets his transactions be write only. I don’t want to replay the transactions to determine the state. Or rather, I don’t want to write the code to do that. This simple little project of mine is starting to get complicated.