This is a pretty useful article about designing ANYTHING.

Aim for your Minimum Usable Design (for designers. For devs, you're looking at Minimum Viable Product, which is VC-speke). Once you've got that nailed down and functioning, you're 50% of the way there. Now set your next goal for 50% of the way to the end (note, that means you'll be 75% done when that goal is met).

Lather, rinse, repeat...


To postmodernists et al: Korzybskis oft-quoted "the map is not the territory" presupposes there is a territory. And he went on to say that "a maps usefulness lies in its structural similarity to reality." Maps are not arbitrary; they should be rational. We understand the universe through mental models - maps - but some maps are plain wrong, while others are the best we can make so far.

via John Meaney, writing Big Ideas, Little Ideas - Charlies Diary.


Austin Kleon, whomever he is, has my profound admiration for putting fingers-to-keyboard and writing this out for us all to share in:

How To Steal Like An Artist (and nine other things nobody told me)

He says in this post, clearly and concisely, so many things I've concluded, discovered, thought about, and believed in for so long, that it makes me insane with jealousy.

To read and understand this article would, I think, without overstating it, give one tremendous insight into my mental and artistic processes.




This is one of the most easily-digested of a gaggle of great images related to web/graphic design that you can find over at

This reminds me of a favoured saying about jobs/work:

You can:

  • enjoy what you do
  • work within the law
  • make lots of money

You may choose two.




Found in a pdf, an assignment from my first semester of DMA, Interactivity course.

These are notes I made in preparation for doing the Crystal Ball gazing assignment:

  1. The future of technology is very portable, wearable, perhaps even implantable.
  2. A principle of corporate content management systems is not necessarily to make
    information/data easy to find (though it must be that), but that the system should be designed
    and leveraged so that the user has the information at‐hand WHEN it is needed, and is
    prompted of that need by the system. The user needn't keep the due dates and milestones in
    mind, but will be prompted by task lists running in the background when things are due, what
    assets they require to perform the task, and where to put the results. This distinction is what
    the author of The Design of Everyday Things (Donald Norman) refers to as "Knowledge‐in‐the‐head" vs.
    "Knowledge‐in‐the‐world." The next step of the task list is triggered by notification from the
    user/system that the step is complete. this can be automatic, e.g. when a file appears in a
    folder of the document library, or manual, as when a supervisory user over‐rides a needed task
    by re‐scheduling or deprecating the task list item. the task list will keep track of items in a
    "hold" state.
    The task list and milestones will be visible to all stake‐holders.
  3. The computing cloud will play an immense role. we are continuing the move, first begun by
    widespread adoption of the internet, of moving discrete file locations from the equation, and
    placing all resources/assets in centralized places. This return of the client/server model is a
    repudiation of the philosophy that kick‐started the PC revolution of a "PC on every desk."
    We've come full‐circle to the recognition of the value of a central repository for
    knowledge/data connected to multiple personal access points. These access points CAN be a
    desktop PC, or a portable PC, or even a simple portable device that can access and make use of
    the repository. Tools to view and manipulate the data are necessary at some of the access
    points, but not all of them. Simple personal devices need not be burdened with large storage
    capacities or heavy applications that alter/create the information.
    These devices need to be easily integrated with clear but flexible models of how to use them.
    The interfaces need to aim for transparency of purpose and use.
  4. The down‐side of "always connected" has been and will continue to be the expectation on the
    part of the organization that the user will be available and able to work with/comment
    on/complete tasks at any time. A clear division between uptime and downtime needs to be
    established and respected.
  5. Wearable devices and their interfaces need to be discreet and sexy. People shouldn't feel
    beholden to or enslaved by their access devices. Neither should the perception of being a "part
    of the machine" be an accepted part of the use of the devices. People would be willing to look
    like Tom Cruise in Minority Report, not Patrick Stewart as Locutus of Borg. (Okay, the Internet
    can provide plenty of examples of people eager to become like Locutus, but we're talking about
    third‐stage adopters here, not the lubricant‐bleeding‐edge.)
  6. Projected interfaces — like keyboards or menus —will need to be very adaptable to the place of use. a flat, table‐like surface isn't always going to present itself. Voice activation/control will also be necessary. Eye tracking and gestural controls need to be developed to the point of invisibility on the part of the user.

blame the pdf for the semi-wonky formatting. I can't be bothered to correct it too much.



This is Atomic.

All the pages you see here are built with the sections & elements included with Atomic. Import any page or this entire site to your own Oxygen installation in one click.
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram