Freitag, 29. März 2013

My Big Fat Christkindle Wishlist

Dear Christkindle,


this is a - probably growing - list of rules, principles and just... nice features that I would rather much like our beloved industry to implement/adhere to:
  • Webshops and web20 frameworks
    • I want ONE way to search, and one customary location for the search field (upper right corner, or upper left, or upper middle... just... ONE location)
    • In general, I want more customs for webpage design, so it gets easier for users to find their way around.
    • Keyboard shortcuts across different websites and web20 frameworks should adhere to a few agreed-upon standards (can you confirm a popup with Enter? Ctrl+Enter? Does Shift-Enter add a linefeed in a textarea?, etc.). In an ideal world, those standards should always reflect the way the user's OS does it, because that's probably the way she wants it.
    • There needs to be some framework that deploys field and form validations to the server and the client from the same source. It is unacceptable that we mess around in PHP on the one end, and then do the same thing (or, rather, hopefully something akin to the same thing) in JavaScript on the other end.
  • Other web stuff
    • There are thousands of sites that fall into a large category of content: For example, there are thousands of blogs out there, mostly consisting of large chunks of texts (aka articles). I want them presented the way I find most readable - in a large, readable font, with columns that contain about 5-6 words per line, and with good contrast (roughly the way the Readability Redux plugin for Chrome does it). The same goes for other kinds of data. 
    • At the very least, the interface should be consistent across ONE site - most sites don't even manage to adhere to that basic idea.
    • Whenever you can design something as asynchronous, you should. I don't understand why I have to wait for the whole form to reload just to realize that I forgot to fill out a field, and when I enter my zip code, I want the damn thing to fill in my city as soon as possible.
  • IDEs
    • Keyboard shortcuts in IDEs should be standardized (especially the debuggers... they're such a pain in the glute, because they use similar-but-slightly-different keys.)
  • Coding Patterns
    • SQL
      • A primary key is an arbitrary value that has no meaning beyond uniquely identifying a tuple. Never give in to the temptation of using user-provided, editable values (such as email addresses) as primary keys. It'll come around and bite you in the abdomen big time! (There is an argument to be made for meaningful keys, as long as they don't change, or change only once every few years - such as a country code. I'm quite undecided in that case, frankly. Overnormalization vs chaos.)
    • Naming conventions
      • I won't make the mistake of starting holy wars here, though I think it might be time to start thinking about some general rules that everyone knows as a matter of honor - as things currently are, I'd be happy if they even existed on a per-team basis, at least. Working with external libraries that have different conventions is a pain in the sphincter, and having underscore_fields in sql, then camelCaseFields in php, but underscore_fields again in your html forms is, at the very least, very ugly - but for the time being, I don't see that changing, so I'm going for second best.
      • At the very, very least, if the database field name is is_locked, then the name in the code should not be isOpen, hasALock, or numOfChimneysInTheFactory. Yes I've seen (and, possibly, even produced) code at a similar level of insanity, sadly.
  • General stuff
    • If an object could be represented as a file, (such as an email or a bookmark, or an actual file in a filesystem) then it should be stored in a hierarchical system of tags, much the way gmail does it.
As you can see, my general principles here are the following three:

  1. The user should not be afraid of the designer, but rather, the designer should respect the user.
  2. Whatever we manage to standardize, is one issue we don't have to think about anymore.
  3. I forgot what the third one was.

2 Kommentare:

  1. Great stuff. Agree with all, apart from perhaps the SQL one.

    Agreed, you don't want a PK which is changing (makes references to it e.g. other tables, URLs which have been sent via email,..) break.

    But I do prefer the use of (non-changing) meaningful primary keys if possible, as opposed to surrogate primary keys.

    E.g. if storing how many clicks a profile got per day, I would rather define (profile_id, day, click_count) with PK on (profile_id, day), rather than create an extra profile_click_id.

    Some frameworks (e.g. Hibernate) don't like that though. (My solution to that problem is not to use them.)

    One consequence of that is that when you have a FK to such a table you have to include e.g. (profile_id, day) rather than (profile_click_id). Although it seems a little unwieldy I think it's a good thing. It means the dependent table has information on which profile, which day it pertains to. You can skip the intermediate lookup in "profile_clicks" to find out which profile the row in the dependent table refers to.

    AntwortenLöschen
    Antworten
    1. Oh I can so see a hot-beverage-powered philosophical debate on that issue in the near future...!

      Löschen