Dev, Data, & Design

Design Links ·  Data Links ·  Conceptual Design ·  UI/UX ·  Programmable Web - A. Swartz

Source

Conceptual Design of Software

Conceptual Design of Software - great overview of research efforts @ MIT.

UI/UX

Download 2011 course materials here - wonderful course on UI/UX.

Don Norman - Design of Everyday Things

Summary of Aaron Swartz - A Programmable Web

Chapter 2 Building for Users: Designing URLs

"URLs, the most fundamentally important part of your website"

Summary

Biggest Constraints:

URLs shouldn’t change (and if they do change, the old ones should redirect to the new ones) so they should only contain information about the page that never changes - pg 9

Cautions
  1. Do not use date-based schemes as TBL proposes
  2. Do not include technical details of the software you used to build your website (for example, '.php')
  3. Do not include facts about the page that might change
  4. Be really careful about classification
Dos
  1. Use incrementing numbers, consider encoding in base 36
  2. Append text after the number to optimize for search engines
  3. Generally use URLs "within directories, not at the top-level."
  4. Use "slugs." Don't change the slug "(or else make sure to redirect all the old ones whenever it changes)"
Non-Nouns
  1. Subpages (which drill down into some aspect of the nouns)
    • Easy Case 1: use a slash off the main page and a slug
    • Easy Case 2: go directly off main site if the majority is a particular subpage (ex. users)
    • Complex Case: when nouns have complex relationships:
      • do what “feels right” for your app.
      • If there are multiple forms, pick one and stay with it
      • If you support multiple forms, pick one as the official one and make sure all the others redirect.
  2. Site pages (help and so on)
    • Consider reserving a subdirectory, ex. '/meta/'
    • Reserve all important potential page names (login, help, about)
    • Pick the sensible URLs for the pages that users come to expect.
    • Be sure to follow all the noun-principles above
  3. verbs (do things w/ nouns)
    • pass the verb to the noun (/v/1234?m=share) instead of passing the noun to the verb (/share?v=1234)
    • dont use subpages, bad example: /v/1234/share
    • converse is true dont (dont use subpages like you would verbs)
      bad example: /p/nancy_pelosi?m=finances

Long Version

Biggest Constraints:

URLs shouldn’t change (and if they do change, the old ones should redirect to the new ones) so they should only contain information about the page that never changes - pg 9

Cautions
  1. Do not use date-based schemes as TBL proposes
  2. Do not include technical details of the software you used to build your website (for example, '.php')
  3. Do not include facts about the page that might change
  4. Be really careful about classification
Dos
  1. Use incrementing numbers, consider encoding in base 36:
    • Skip confused numbers/letters: zero, O, one, L, or I
    • Skip all vowels to to avoid certain words
    numbers are not optimized for search engines, so...
  2. Append text after the number
  3. Use URLs "within directories, not at the top-level."
    If your main nouns are subdirectories themselves,"... "it might make sense to break this rule", like twitter (ex. http://twitter.com/aaronsw)
  4. Consider a "slug."
    • "A slug is just a little bit of text that looks good in a URL
    • These can be user created (or auto-generated from the title by default.
    • Don't change the slug "(or else make sure to redirect all the old ones whenever it changes)"
Non-Nouns
  1. Subpages (which drill down into some aspect of the nouns)
    • Easy Case 1: use a slash off the main page and a slug
    • Easy Case 2: If majority of your site is subpages
      ex. a twitter's user account is at http://twitter.com/aaronsw and status messages at http://twitter.com/aaronsw/statuses/918239758. (Note: The “statuses” bit is redundant and the number way too long.)
    • Complex Case: when nouns have complex relationships, for example: Delicious, where users post links under various tags. How should things be structured? user/link/tag? tag/user/link?
      • It’s hard to give general rules for how to solve such inter-linking problems; you basically have to do what “feels right” for your app.
      • It’s tempting to just not decide and support all of them. This is problematic as it creates duplicates (books/user, user/books)
      • You really want to pick one form and stay with it, otherwise you end up confusing search engines and browser histories and all the other tools that try to keep track of whether they’ve already visited a page or not.
      • If you do have multiple ways of getting to the same page, you should pick one as the official one and make sure all the others redirect.
  2. Site pages (help and so on)
    • one trick is to reserve a subdirectory, ex. '/meta/'
    • if you're not expecting a lot, reserve all important potential page names (login, help, about)
    • o just pick the sensible URLs for the pages that users come to expect.
    • be sure to follow all the noun-principles above
  3. verbs (do things w/ nouns)
    • pass the verb to the noun (/v/1234?m=share) instead of passing the noun to the verb (/share?v=1234)
    • dont use subpages, bad example: /v/1234/share
      1. That way the verb works even when your nouns already have subpages
      2. It makes it clear that the page is meant to do something, not just convey more information
    • converse is true dont (dont use subpages like you would verbs)
      bad example: /p/nancy_pelosi?m=finances