Intel has invited me to participate in their Ultimate code challenge, so for the next 7 weeks i will be working on supporting some cool new tech and blog about it on intels developer site. For people not reading it, I will repost everything here too.

Your
PC is an amazing peace of kit, it’s amazing because no other computing
platform is as versatile and no other platform is so open for
innovation. You can buy hardware for it from thousands of vendors, you
can hook it up to just about any display or input device and you can
make it do just about anything. While maybe no longer being the latest
buzzword, the combination of screen, mouse and keyboard, is still the
best way to be productive, get a headshot or to create the next software
wonder. Whatever cool mobile app or console game you think is the hot
stuff, it was conceived on a PC. If we could only choose one computing
platform it would have be the PC, for the simple fact that no other
platform could exist without the PC.

But all is not well in the PC world.

If it was, then how is it that my Amiga 1200 was able to boot from
power on to desktop in less than 2 seconds when it takes the better part
of a minute to do so on my i7 Machine with a 500meg+ a second SSD? How
is it that when I type in text in to a modern word processor it
sometimes lags behind when it didn’t on the Commodore 64? How is it that
it takes a minute to search for a file on my PC hard drive when Google
can search the entire internet in a fraction of a second? How is it that
Facebook remembers every click I make, but my own computer can’t
remember where I left off the movie I was watching last night? While
Intel and others have done an amazing job shrinking down processor
wiring down to the thickness of a few atoms and making processors able
to do billions of operations per second, we as software developers
haven’t really done our part making the software.

While the tablet or phone operating systems have yet to become
platforms where I can get proper work done, or do complex tasks like say
having two browser windows open on the same screen, I think the PC
needs more attention. It should not be seen as technology of the past
but as a starting point for where we want to go. What we really want is
to have the openness and flexibility of the PC everywhere. Our phones,
tablets, laptops, workstations, TVs, even walls should all be PCs so
that we can freely move software, files and tasks from one to the other
and never let the hardware form factor dictate what software we can run
on the device. What we should have is software that transcends the
physical hardware.

The interfaces we have on the PCs aren’t really adapted well to work
on a wide variety of devices. While we want to keep the open nature of
PC hardware, we need to change our software design so that the desktop
of the future would no longer be familiar to someone using a Xerox Alto
in 1973. We need a new paradigm for the PC.

My goal with this challenge is to show what the PC could be, how we
can develop software that can run well on a range of different hardware
setups, from screen resolutions to input devices. Intel has provided me
with some great new hardware, and I intend to show just how great PC
software can be for these devises, if we only spent the time to develop
it rather than just focusing on closed platforms. There are many things
to improve but with only 7 weeks I will focus on building a framework
for graphical interfaces. I will apply this work on at least 3 different
applications. A game, a data visualizer and creative tool.

I will be writing an open source software layer that makes it easy
for any developers to make use of the diverse hardware available to us,
and makes it possible for hardware vendors to experiment with new
hardware configurations, without forcing us as developers to rewrite our
applications in order to take advantage of them. If we are going to
consider how to write applications that are independent of hardware, we
first need to consider the types of usage scenarios and pros and cons of
different input devices and how they should be supported.

If we are going to write applications that can run on almost any form
factor with any kind of input device, we need to think about the
limitations and opportunities it creates. To begin we should probably
assume that the device has some kind of pointing input device, so we
want to create an API that unifies the concept of pointing, disregarding
if its multi-touch, a mouse, a Wii remote style device or (god forbid)
a track pad. If we are stuck with a non-pointing input device like a
joy pad, we need to figure out a way to make applications useful anyway.
We should also figure out a way to support an “escape” with every
interface. This could be something like the windows key, or the iOS home
button, something that can always be accessed to connect with the
operating system. We also want to support very wide range of display
sizes and resolutions. All the way from your phone to large displays
that may cover and entire wall. Large enough displays means that we want
multiuser support too. That creates some interesting challenges since
we can no longer assume that two multi touch events are triggered by the
same person trying to accomplish the same task. We also must consider
that the user many not be able to reach all parts of the screen, so we
can’t have any static menus or buttons, like a start menu, taskbar, dock
or Apple menu. We will need to solve most of these things with popup
menus. We should obviously support a keyboard, but we should also
provide some kind of pointing based fall back for typing.

To display our interface we should not assume that the pixel
resolution in anyway corresponds to the size of the interface. All
interface elements should therefore be vectorized and scalable. We also
want to support an interface that takes in to account the users view
angle, this means the interface must be 3D. If we build a 3D interface
we can easily support stereoscopic displays, head tracking, head mounted
displays or augmented reality applications.

This first week I will dedicate to building an API that will be able
to provide application developers with all these things and also let
hardware vendors make drivers for it. Next week I will talk about how I
go about doing this.

It’s going to be a fun ride!

Cheers

E