Matt's profilemattmacBlog Tools Help

Blog


    March 02

    Boku Product

    Not sure how much I can say, but I know I can say that Boku will be shipping as a product for the XBox in the next 12 months. Huzzah :)
    August 09

    I Lived On the Moon

    Okay, this is just plain super-beautiful.
     
    I Lived on the Moon is a short-form animation by Yannick Puig. 
     
    It combines CG, stop-motion animation (simulated using After Effects,) scratchy film grain, and deep, powerful archetypal imagery to create a world of sad beauty and swirling nostalgia.
     
    The muted tones and shadowy landscape speak strongly of the eastern european visual tradition, but Mr. Puig appears to be French.
     
    Watch it and be amazed at the power of individual vision.
     
    The entire video is available on the site - it takes a little while to download. The site shares lots of interesting tidbits about his creative process, tools, and influences.
     
    August 08

    Programming: Like Karate for your Brain

    Programming is good for you. Even if you don't program for a living, programming stretches your mind in ways that are very beneficial.
     
    Think about it. Even if you're just working on something boring like a calculator program, your brain has to simulate what the computer is going to do so that you can construct your plan correctly. When something goes wrong, you again simulate many different possibilities mentally to form a theory about the bug - and to correct it.
     
    Simulation itself is a very interesting special case of programming. Building a sim is like a multidimensional form of writing a story. You're not writing one story; you're construction a story space in which an huge number of different stories can happen.
    - story: keep track of who did what when
    - sim: keep track of who can do what and what new possibilities will emerge if they do it
     
    Learning to simulate complex systems in your head is great practice for a lot of jobs - like running non-profit organizations, effecting social change, or running a car dealership.
     
    And simulation, as we know, is just a polite word for gaming.

    Programming - or, more precisely, the mental facility developed by programming - is a life skill that should be accessible to everyone. Game programming is a great place to start.

    Academia is noticing. Two interesting events this year:
     
    Programming - the fourth R?
    April 16

    Keeping User Generated Content Beautiful

    99.9% of everything sucks. It takes a combination of timing, luck, talent, perseverence, and insight to create something truly cool. We all make stuff that sucks for different reasons; we get bored, distracted, don't do our homework, etc.
     
    We all have our moments of outstanding quality as well.
     
    How do we connect with .01% of content that we really want? The "miracle" of modern media conglomeration is content filtering. Sometimes this works really well; I wouldn't know about any of my favorite music if there hadn't been an arbitrating record company pimping their tracks worldwide so that I could find a great Manchester freak band from all the way in Santa Cruz.
     
    So mediation serves a useful purpose.
     
    Unfortunately for those media conglomerate dudes, disintermediation is even better, because it scales. Someday before too long, I'll find my next favorite band through a really good recommendation system that lets millions of listeners review content from thousands of bands. The wisdom of the masses is incredibly powerful, and the really good part is that one million editors can review and evaluate a lot more content than one hundred. That's the theory; unfortunately, this model has not really worked out for music. That's a topic for a later post.
     
    For the game industry, there are different content challenges. If you've spent more than ten minutes in Second Life, you've experienced the User-Generated-Content-Sucking problem first-hand. Awkwardly scaled textures, cardboard buildings, blindingly hideous animated GIFs, you know. Not good.
     
    The fix in this case is in the tools. If you want to give users the ability to make games, don't hand them polygon editors. You want their ideas, not their vertex manipulation capabilities. Put another way, if you want your users to make movies for you, make them directors - not scenery carpenters.
     
    What I'm talking about, as many of you have guessed, is procedural artwork.
     
    What we want is a content engine that has rules for growing things like trees, rocks, and even buildings. There is good technology out there for encoding architectural rules so that an infinite number of unique buildings can be generated randomly - or with guidance.
     
    In the game development environment of the (near) future, all of us will be powerful "directors" with an army of talented robot artists at our disposal. We get to focus on the big picture - where the buildings go, how they connect - while the software figures out how the individual bricks are arranged, and how the mortar is applied around window frames.
     
    The direction we want to go is that game creation becomes a process of transcribing vision directly into the machine. We just need to give the machine a rich enough language.
     
    April 08

    Tesler, Newton, Hindsight

    I worked for Larry Tesler back in the 90s. He's always remained one of my favorite people for his combination of intelligence, creativity, realpolitik, and a deep and genuine desire to make computers and the world a lot better.
     
    Larry was VP of Advanced Products at Apple when I was on the Newton team. I worked on a prototype, large-format version of the Newton called Bauhaus, which used an object-oriented dynamic language derived from Lisp (Scheme) called Dylan. Dylan was a great language, and Bauhaus was one of the coolest pieces of software I ever worked on. I did the user interface and interactive graphics layers.
     
    At this time, Larry was of course a full-time manager, but he did have his five-year sabbatical coming up. Me and three other folks (Jim Grandy, Yu-Ying Chow, and Mikel Evins) were given four months to prove that Dylan was performant enough to deliver a compact and compelling user experience on the larger Newton. (we did) After the first few months, Larry decided to spend his sabbatical writing code with us. I frequently slept in the office over that frantic, beautiful summer, literally waking up, stumbling over to my Mac, and dropping right back into the code I had left the previous night. It was a great time, and we did some great things - for another conversation.
     
    So I'm reading What the Dormouse Said, (see previous) and realizing that Larry was not just the brilliant manager I had known, but had spent his own grungy all-nighters in his youth inventing things like, y'know, pop-up menus. The event loop. Bit blitted graphics. Icons. The modeless user interface. Sigh. Newton, malformed, beautiful mutant that it was, was part of a history for him that went back to the first foundations of the modern user interface. I kind of knew - but I never quite ... realized.
     
    Do we ever realize how truly cool people are while we're still with them, or is it always just fond remembering?
     
    UPDATE: Yes, Larry Tesler is alive and kicking. We just work in different places now :)
    March 29

    Creativity Without Community?

    In boku, you can credibly build your own little game. But you're on an island - you can play your game, and someone can come to your house and play your game.
     
    The next step would be that you can email your game to someone.
     
    What we *really* want is to be able to seamlessly integrate sharing - so you can share your games by clicking on a button, and see what other games people have shared. And which ones are cool (rating system) and which people are making a lot of cool games (reputation system.)
     
    When we all learned coding, we exchanged code all the time.
     
    Our group is called Creative Systems. We were thinking of calling it Creative Communities, but that is a lot of syllables and a little stiff. So we decided that "creative" implies "community."
     
    Does it?
     
    March 28

    Dormice

    Still at Etech, post my boku presentation.
     
    On the way down I was reading John Markoff's fantastic newish book What the Dormouse Said. It's about the birth of the personal computer at SRI and PARC starting in the sixties.
     
    It's pretty amazing what those funky old geezers were pulling out of the ether in the SIXTIES. Makes me feel like we've been doing an awful lot of resting on their laurels.
     
    Logo was released in 1967. Douglas Engelbart's breakthrough GUI demo was in 1968. Lisp never went mainstream, but at least we've have some crazy new scripting languages around. I'm happy about C#, but GEE where's our revolution gone?
     
    Wrote a rant/screed a few months back about how we should turn the XBox 360 into a cheap monster workstation for schools. Public schools. With really cheap (dare I say public domain) educational content, great content frameworks like XNA and XBox Live, and, y'know, boku for the little kids.
     
    I remember back in the early 80's sneaking into the computer center at UCSC to play with their raster terminals. Gigantic CRTs that could display a full-screen color image. XBox makes these look like a lite brite. And, because it's a commodity, it's just getting cheaper. Developing sophisticted media for the PC is a pain because no two PCs are the same - what looks great on one won't run on another, so you have to do common-denominator stuff. On the 360, you know what you're running against.
     
    Most educational media is crappy because the common denominator for school pc hardware is barbaric. Fixing that for $300 a pop seems like a no-brainer - maybe then we'd see amazing molecular simulators in high schools rather than grainy animated gifs.
     
    I dunno, I like that idea.
     
    Just an idea, though, folks. Not a "secret product." :)
    March 21

    Boku Surfaces

    A few weeks back, we revealed Boku to the world. I blogged a while back about programming for tots, which was the original motivator. At that point, I wasn't being elusive - we were just getting started.

    Now we've demo'd for the world, and even got picked up by some video feeds. Wired did a nice tiny summation of what Boku's about, and even included some pictures. We got a lot of nice press, still available if you search around for boku & techfest.

    For the best take, see my demo in the Techfest keynote. It's a Windows Media asx file. My demo is about 35 minutes in.

    I'll demo at E-tech next week. Say hi if you see me there - I'm minus the beard now :)


    September 28

    Everyday Creativity

    Many people wish they were in a more creative line of work, or that they were "a creative type," or that their environment "appreciated creativity more."
     
    Culturally, we have a lot of respect for creativity, and geniuses like Edison or Frank Lloyd Wright are seen as dramatically different people from the rest of us. While those guys are heroes to me, I think that the veneration of creative genius can create real barriers - making it seem as though creative expression is the privilege of a few.
     
    When you really break it down, what is creativity? It is the act of making something new. This is more often a matter of assembling things that already existed in a way that is more or less novel - expressing a concept, an image, or an emotion.
     
    Seen this way, creativity is everywhere. Speaking is creative. Emailing is creative. Blogging is creative. Even those blogs that just cut and paste things from other blogs are creative - just as a painter combines existing colors in a novel way, cut-and-paste blogging assembles diverse perspectives in a distinct mosaic.
     
    This is recognized legally; you can actually take a collection of simple, public facts and get a copyright on the way you have arranged them. Commercial databases (like www.allmusic.com) do this all the time.
     
    The revolution of blogging, rss, myspace - it's an evolution of creativity. It's a recognition that we are not a society with nothing to say, sprinkled with a few special "creative types." We are billions of people bursting with ideas and emotions that are dying to get out. We don't all have time to write a novel - but it turns out a heck of a lot of us have a few minutes a week to write a post.
     
    For every 1% easier we can make it for people to create and to share those creations, we will get 100% more creative product - multiplied by billions of people worldwide. Everyone has imagined a story, dreamed up a game, and hummed an original tune. There are an awful lot of cool songs, games, and books on the other side of that wall...
     
    September 15

    Pre-Literate Programming

    My daughter is 2. Soon she'll be 3. She can form sentences, and she can assemble objects. She can't really read, but she can pick out letters.

    How soon will she be able to program? What is the earliest we could put some form of programming tools in front of her? I'd guess probably "late 3" to "early 4" if we give her a visual programming tool - one that lets her assemble objects, sensors, and behaviors.

    Braitenberg's book Vehicles illustrates fascinatingly complex behaviors that can be built from extremely simple circuits. (It's a classic of artificial life.) This, to me, is "programming enough."

    So let's build a programming tool that is entirely non-textual (please, no more scripting languages,) has an extremely simple UI, and can build fantastic dynamic systems.

    That's fun...

    September 08

    Novel lecture on realistic oil consumption reduction

    From TreeHugger:

    In a talk that rivals William McDonough's 2000 Bioneer talk (see the video here) in vision and pure tree-hugging goodness, Amory Lovins details how it is possible to massively reduce our oil consumption with current technology, at a profit, while creating new jobs, without paying higher energy prices, and without drastic new regulations. It's a long and detailed presentation (about an hour and a half), so make sure you have some free time and are comfortably seated before watching it. But please, do watch it and check out ::Winning the Oil Endgame (the book is available in full on the website). Thanks to MIT for making it available to the public: ::Video of Amory Lovins on Winning the Oil Endgame (if you need a Realplayer codec, try the freeware Real Alternative).

    July 26

    synthetic art eats spam, creates beauty

    Automatic synthesis of geometry and textures is a critical technology for interactive enterainment. It's seen as a key bulwark against out-of-control game costs and relentless pressure for more detailed game worlds.
     
    There's a rich vein of research, and the xbox 360 has hardware circuitry designed specifically to facilitate real-time geometry synthesis.
     
    Alex Dragulescu uses spam as input to drive a geometry synthesis engine. The results are beautiful and compelling.
     
    From CNET:
    April 26

    I Miss HyperCard

    Are you old enough to remember HyperCard?
     
    This was one of the most innovative and exciting pieces of software ever written - it's sad how far it's fallen from the public mind.
     
    HyperCard was a programming tool for people who didn't consider themselves to be programmers. For a few cool years, all kinds of people built neat little graphical programs using hypercard - useful things like calculators and accounting software, and fun stuff like interactive games. The guys who built Myst, which was huge, first built the Manhole, which was like an interactive, non-linear childrens book, using HyperCard.
     
    It would be great to see something like this happen again.
     
    You might say that this is what the web is, but there's a missing piece.
     
    HyperCard feature a very neat, very nimble integration of an abstract data model with a visual user interface (it's not a coincidence that HyperCard was written by Bill Atkinson, one of the key original creators of the Macintosh.)
     
    For example, HyperCard had the concept of a foreground and a background. The background served as a backdrop behind several cards: the foreground was unique to each card. You can put data fields in the background and then have their contents in the foreground - this lets you visually build a schema without understanding what schema really means.
     
    We have much fancier, more powerful, and easier-to-user development tools today. But the magical combination of easy usability, intuitive design, and abstract power have not been matched since. It's interesting to think about what form today's HyperCard would take.
     
     
    March 31

    The Formula

    My favorite rule from software design is a classic: defer detail.
     
    This applies at the user interface level, object model, or to good old structured programming.
     
    Painters do this too: rough in large areas of color and shape, come back over sculpting and tuning, and finally make a pass with the tweezers and the magnifying glass, getting every hair in place.
     
    When you're in a well-funded organization, there is a huge temptation to do all these passes simultaneously. Nobody wants to be the deer in the headlights when B** asks about some obscure detail. Saying 'we don't know yet' is out of style.
     
    But it's often the right thing to say.
     
    Designing interesting things is largely a process of managing ambiguity. This is a very different thing from making decisions, although they are interrelated.
     
    The thing with software is that any non-trivial system involves a good deal of discovery. Humans are not particularly good at simulating large complex systems in their head. The result is simple, but I'll give it its own paragraph:
     
    You will learn more about the problem space as the code progresses.
     
    Waterfall people will say that all the discovery should happen on paper, in the design document.
     
    Should, sure. But won't. It's much better to understand and tolerate the right kinds of ambiguity in the design process.
     
    Solve the solveable things first. Implement those solutions. Check if more things have become solveable. Repeat.
     
    In large teams, where you can afford to assign a person to every unsolved variable, you invariably wind up deciding things too soon. These decisions don't last, because they were not based on enough data.
     
    So the mature project manager sees his job as not making sure that every decision has been made as early as possible, but making sure that the right decision are being made at the right time and in the right order.
     
    Every good design is a gigantic formula with hundreds of variables. Part of the formula is in the design, and part of it is in the code. As such, some issues will not be resolved until enough code has been written. We all know this, yet we ignore this crucial knowledge every day, and we are mildly embarassed when we say "I don't know yet - we'll have to see it working."
     
    When you try to decide undecideable things to early, you are simply inventing values for unsolved variables and inserting them into the formula. This leads to propagation of errors through the design, leading to failure or backtracking.
     
    A Psalm to Correct Sequencing:
    Oh Great Code
    Give Me the Knowledge to Decide the Decideable
    The Courage to Defer the Deferable
    And the Wisdom to Know the Difference
     
    :)
    February 17

    White is the New Grey

    Much love google. We love how you've raised the game for quality interaction with software. Text-only ads, free services, highly responsive UI (well, for the web, anyway - snap!)
     
    Methinks, however, that in a few years time, large white areas in the UI will be about as exciting as large wads of embossed battleship grey plastered over everything.
     
    At about the same time, shiny jellybean buttons will have become tiresome as well.
     
    We're moving the through the 50's of user interface style:
    - on the apple front, we have the 50's cars - beautiful tailfins, smooth lines, a notion of being streamlined without the benefit of actual wind tunnel testing
     
    - on the google front, we have the late art deco - geometric forms, juxtaposition of simple geometry, high focus on typographic elements
     
    Here in the pacific northwest, we're chasing both of these simultaneously, which runs the risk of putting us square in the 70s - a pastiche of played-out trends, hopefully remixed but sadly dated.
     
    Putting aside for the moment of whether a user interface should have a voice, where should we look for what that voice should be?
     
    In my mind (where it shall sadly remain, as I'm not as good a designer as I'd like,) the right direction is east - zen, origami, simple honest materials, minimalism, sensitive use of contrast, and just a touch of imperfection - the flaw that proves the integrity of the whole.
    February 15

    User Model for the Cloud

    So we all know that eventually the center of our daily computing experience will be online.
     
    Today, it's still all about this physical artifact, this computer.
     
    Tomorrow, it's about the cloud of objects I create, own, have received from others, or am interested in.
     
    What will we use to manage these things?
     
     Put another way, what's the smallest set of concepts we can define that will allow us to keep a good picture of what's going on with our stuff?
     
    Here's one take:
    - things - a basic atom of information or ownership. a file, but also a blog post, or an entry in a contact list
     
    - groups - aggregate collections of things
     
    - names - I need to be able to name things - groups of things, or individual things. I need to be able to reuse these names. Conversely, I need to be able to guarantee that some names are unique.
     
    - rules - Things have different ways of entering my ecosystem. Because I am a modern human and completely overwhelmed by a nonstop flood of information, I will need a system of rules that process incoming items to make them more consumable, findable, or ignorable. Not just incoming items, either - but items changing in any way. Any dynamic property of the system should be able to trigger any action that I can apply myself.
     
    - privacy levels. Privacy is the ultimate security; it generally encompasses all others. If you can't find or see something, you can't overwrite, edit, copy, or delete it. So if I can control my privacy I'm most of the way home. On a different topic, I don't think anybody should ever be able to overwrite, edit, or delete something of mine - at least not without leaving around a copy of the old version. That's a whole other paper, though.
     
    - versions. This one's just obvious and overdue. If I make a new version of a document, my user interface needs to know what that means. No more playing games with renaming documents, ("Final Version .12", anyone?,) and certainly no getting on the plane with the wrong version of the presentation. The computer is much better suited to keeping track of this garbage than I am, and in the world of the cloud, the problem reaches a critical mass. Versioning is a central part of the system
     
    - places. All this abstract stuff doesn't make much sense if you can't connect it with other people and with the physical world. Places are where the virtual world meets the physical. This laptop is a place. My other computer is a place. Hotmail is also a place, and so is spaces.msn.com/mattmac. A general concept of places encapsulates an awful lot of the unimportant esoterica of devices and services while simultaneously providing a place to hang all that esoterica for when you need it later.
     
    - people. Are in there too. I bet you have all kinds of ideas for how they matter to the system. More later.
     
    This is all really buildable. We're working on it.
    February 08

    3D UI - Get Serious

    Every experiment I've ever seen in 3D UI has been pretty cringe-inducing.
     
    Nevertheless, I believe that all UI will eventually be 3D.
     
    More specifically: every user interface framework in 2020 will be capable of transforming any UI element in 3d space, and we will see cinematic effects like focus, motion blur, and haze in common desktop UIs.
     
    The reason is not that those things are cool. The reason is that those things are all useful.
     
    If all you have is a horse and buggy, you might not understand why more aerodynamic paint is important. But as users get more powerful tools for dealing with a faster and denser flow of information, little problems with today's UI will get more significant.
     
    Put more positively, things that seem like polish now will seem like efficiency tomorrow, and like necessity after that.
     
    For example, consider perspective. Perspective is a really brilliant accident. Perspective makes things that are close bigger and vice versa. This means I can see more detail on things that are important to me, and a larger overview of things that are less important. Perspective is used in cinema and visual design all the time to stratify inforamtion for easy consumption. Once tools and infrastructure are available, serious designers will find excellent use for such a compelling principle. it's inevitable - once we have the tools.
     
    Right now we are in a catch-22. Devs won't write the tools unless there are good designs that require them. Designers can't make good designs unless they have the tools. Who will break the logjam?
     
    We'll see.
    January 30

    Laws of User Interface

    1. I am king
    This is my computer. I bought the applications and the operating system. This computer has no purpose in life save to serve my needs.
     
    2. Acknowledge all user action instantly
    Sometimes the computer is busy doing something the user asked for. That's okay. What's not okay is locking up the UI while I wait. Whenever I click, type, or simply hover my mouse, the application must respond. Failure to acknowledge user action for more than .25 seconds is unacceptable - always.
     
    3. User input is sacred
    Whenever the user types something, be extremely reluctant to throw it away.
     
    4. Don't make me tell you twice
    When I've entered data, it's your job to make it available wherever I need it. Don't make me paw through multiple screens so that I can take something you already know and tell you again.
     
    5. Everything's interruptible
    If you're doing something that takes more than .25 seconds, you must give me a way to tell you to stop doing it. It may take time for you to stop, and that's okay, but you must tell me you're stopping so that I can do something else while you finish up.
     
    6. User interface is not interesting
    I'm glad you spent millions developing your UI. The result should be that the words "user interface" never occur to me, because I'm instead looking at my own stuff. UI should be understated at all times. Hint: if you like to show it off to your designer friends, it probably doesn't belong in my UI.
     
    7. Details matter. All of them.
    If you want to have a curved line in your UI, it better be anti-aliased, alpha-blended, and rendered with sub-pixel precision. This is the 21st century, folks.
     
    8. Contrast is a precious resource - spend it reluctantly
    This skin, for example, is bad because it uses high-contrast lines all over the place and then makes my content low-contrast. This is exactly backwards. The human visual process is designed to focus exclusively on high-contrast edges. Reserve high-contrast for things that matter, and make everything else fade softly into the background.
     
    9. Everyone understands quality
    Don't count on a user to explain these rules to you, or to ask for things like clean anti-aliasing. They don't know the language, but they do know what they like. Users who are not interior designers still prefer to ride in a Lexus. Be a Lexus.
     
    10. You are not cool
    Your user is cool. Their content is cool. Showing the user their own content is cool. Making the user look at your boilerplate content is dumb. Get out of the way and show the user their own stuff.
    January 23

    Ajax, Privacy, and Memory

    Much has been said about the fantastic power of Ajax - you can implement very responsive UI within HTML. I like this stuff a lot and am regularly impressed by how far people push it.
     
    Some theorize that Ajax will eventually subsume the interesting 80% of the desktop UI that 80% of the people in the world use. That may be, but there are substantial barriers. The first is the lack of a local memory accessible to Ajax clients.
     
    Most simply put, the internet security model - to generalize grotesquely - depends on bifurcating the two worlds of computing into online and desktop. Online applications that do anything with your desktop data are highly suspect, and a webpage that works with your desktop data would set off alarm bells - and rightly so.
     
    It's hard to teach people about security, so we simplify - and people have learned that protecting their machine from intrusions by anything running in a browser.
     
    Bottom line: Ajax does not provide a facility for interacting with local state. This causes two problems:
    - applications cannot tailor themselves over time to better fit user behavior
    - or, if they do, they must rely on server-based state, thereby tying users to particular services
     
    Moreover, if you do rely on a server to keep personal information about you so that it can provide a more adaptive and useful service, you are also allowing the service to use and probably exploit that information. So in order to run your application in a web browser you are willing to share private information with a service. Is that really a good trade? It's a good question to keep in mind.
     
    As usual, we ask: what's in it for the user?
     
    I expect to see people pushing on this issue in the year ahead. Interesting to see what happens.