Tuesday, March 13, 2007

Back to basics

And a bit more research on interface design for PDA's. Still having trouble with it...
Interesting article on "Guidelines for handheld mobile device interface design here.
Obviously some more research into Shneiderman's "Goldon Rules of interface design" however this is very limited. For my head here is the list of rules that are applicable to mobile devices:
* Enable frequent users to use shortcuts
* Offer informative feedback
* Design dialogs to yield closure
* Support internal locus of control

Enable Frequent Users to Use Shortcuts
As the frequency of use increases, so does a user's desires to reduce the number of interactions
and to increase the pace of interaction. Because time is often more critical to a mobile device
user. Reducing the number of operations needed to perform regular (i.e., repetitive) tasks is a key factor in the ease of use of mobile devices.

Offer Informative Feedback
For every operator action, there should be some system feedback, such as a beep when pressing a key or an error message for an invalid input value. (This also relates back to reserach carried out a while ago on the timing of page changes. Too long and the user gets bored too short and the user doesn't realise that anything has changed.)

Design Dialogs to Yield Closure
Sequences of actions should be organized into groups with a beginning, middle, and end. Users
should be given the satisfaction of accomplishment and completion, no matter whether they areusing desktop computers or mobile devices.

Support Internal Locus of Control
Users want to be in charge of the system and have the system respond to their actions, rather than feeling that the system is controlling them. Systems should be designed such that users initiate actions rather respond to them. This guideline is applicable both to traditional desktop
applications and mobile device applications.



The limitations of mobile design
"Mobile device interface design is more restrictive than desktop interface design because of relatively limited computing and communication power, smaller platform sizes, an always-changing context, and smaller amounts of user attention" I did at one point reserach Holland and Morse investigated on audio interface that leaves a user’s eyes and hands free for other purposes. However this is going against my need for visual design.

Wednesday, February 28, 2007

"It is a mistake to think you can solve any major problems just with potatoes."
Douglas Adams
-----------------------------------------------------------------------------------------------
Back to the problem of design. Now I have sorted out the interfaces - well in that they work... and should do the trick and I've spent the week trying to make them look asthetically as pleasing as possible. And as I'm sure were all getting bored of hearing, and I'm certainly bored of typing/thinking/pondering; the screen size, this is the problem. Again. Its just too small to work with. When designing a web page, or an illustration, or whatever, you make the window size whatever size you want, size is no object (over the constraints of the screen size obviously). I keep getting drawn back to how I would design this piece in a perfect world. First off the general design I would make the background fancier - a Victorian style border, torn edges, different papers, materials, animated elements. I would use animated transitions between pages and use more illustration to show this. For the user input screens I would use a typewriter, and have the input sections as an old book - make the paper fly away when you submitted your answer. I would have the question screens with the animated elements also in a book - instead of blunt page changes I would make the viewer turn the pages of the book (yes its been done and is slightly 'passe' but still.. I like it)I would use a time machine a bit more - could have it flying around or teleporting through the pages. Maybe a Doctor Who effect - fuzzy blending with some interference to the picture. The possibility's are endless. I need to think this through more........

Tuesday, February 13, 2007

Tuesday, January 30, 2007

Conversation between me and I (Well more like an argument)

So I’ve just come back after having a cheese and tomato sandwich and a cup of strong instant foreign Nescafe coffee (It’s cheaper but I’m sure stronger) after writing the last post. To save time and wastage of worry time, I’ve tried to put into words or thoughts what I’m worried about and tried to resolve them.

So what’s your first worry?
The structuring of the flash document. Up until now I wasn’t quite sure how this worked. As it is Tom’s job to put together the final programme on the IPAQ’s I’ve kind of left this thought behind however it keeps coming back usually late at night. The reason it came back this time was after writing about the hourglass animation.

So how does it work?
Well to begin with I assumed that there would be one long continuous flash document which would work like a normal one with buttons and a navigation system, using Action Script etc. However it came to me while getting the components of the sandwich together on the chopping board – Bread, cheese, Tomato, Pepper that this is not the case. Each hotspot that you walk into will obviously call up a separate SWF, JPEG, WAV, file. There is no need to panic about the programme navigation or coding as it is actually very simple.

So what’s the problem then?
This got me thinking about the remembering part of the game. The toolkit does have simple programming, whether we use this or HTML I am not sure, however the programme does need to remember certain parts. For example did you get all the clues right, did you even try them all, were have you been, etc. It then needs to store the information obviously now in a database. I am not a database kind of person. Especially not making flash work with a database system…… And if this is the case I will also have to make some of the SWF’s have multiple versions. If you have solved this this and this then you get this if not you get this etc.

And what else?
My original idea of the drag and drop for the clues might have to be abandoned also. When you make text an object you are essentially making the text a picture. A picture can no longer have words read out of it. To explain: In Photoshop when you flatten or rasterised text you are essentially flattening it. When you put the text cursor over it you can no longer edit the text; it is now a picture. It works on the same principle as Flash. To allow the letters to be dragged and dropped into the right position you have to make it an object. Therefore Flash will no longer be able to read what it says. IE we won’t be able to put it into a database because there won’t be anything there. Or can it?????

Right…. Well you need to think about that then.
Yes….

So what’s this about the hourglass then?

Well, as I have previously mentioned the hourglass will be on the screen when ever there is nothing else. Originally I wanted it to be true to time at the beginning of the game the sand is all in the top and as the game goes on the sand falls down. As I said there are already problems with the coding, in that I can only do it using JAVA. No idea how this all works on the IPAQ’a, I should but I don’t… However while congratulating myself on the realisation that there will be separate SWF files it dawned on me that to have a consistent time lapse ie one hour, the hourglass would have to be running constantly. Now I might be able to allow the SWF to know when it has being turned off, and therefore re-start at the same point however I do not know how to make the SWF think it has being running the whole time.

Oh dear….
Yes. However this got me thinking that maybe Mobile Bristol can be playing a file the whole time, yet does not display it on the screen the whole time???? I DON’T KNOW………………………………………………..
Ah ha! Tom has just come back and informed me that you can be playing files constantly without them showing. Now I just have to work out how to make the Java work……………………….

Right well what else?
The map. While thinking this through and pondering how to show it on screen I started thinking about how it shows you where you have being. This will all have to be done using multiple flash files. The Mobile toolkit will then have to do all the leg work in knowing where you have been and directing the right SWF to the screen. So I started to think how many SWF files this will entail and I worked out about 25. This does not cause problems in itself; however I’m beginning to worry about the Toolkit that is going to be directing them. Will we be able to do this? Basically without being able to work out Databases and Flash, and the programming on the toolkit were screwed.

Current Investergation

We have decided on a few aspects of the game which is my chosen route of investigation over the next few weeks:

* We need a map for the player to be able to see at any time, or at least some of the time. Due to the constraints of the screen I need to find a way in which the viewer can just view segments of the map. Need to think about the best way in which to achieve this segmentation. As there is no keyboard the usual method of pressing minus and plus cannot be used.
* The screen of the IPAQ needs to be looked at. The size 5.5cm/7.5cm does not leave much to be worked with. The colours will be important as well the contrasts. As the game will be played at night (to reduce sunlight problems, reflections etc) this is also something which might possibly cause issues.
* All of the clues will have to be entered into the programme by the player. This means setting up a ‘password’ style flash page. This in itself is not a problem however the way in which the player will do this is. Again lack of keyboard means that there will have to be another way around this. First thoughts are drag and drop, but then there’s the screen limitations etc.
* The Hourglass animation which will be on the screen when nothing else is, to show the passing of the time and to remind the player that there is a limited time span. Have figured out how to time it so it can last an hour however it relies on JAVA which I’m not sure the mobile Flash can support. Have no idea where this information can be found. Another way would be to not use JAVA and find another way around the time issue. A clock would be simply, however the animation of the sand running out is causing me sleepless nights. I might have to resort to just using a simple timer/clock which is going against the original design. Or simply having an animation of the hourglass which bares no resemblance to the actual passing of time. Every 15 minutes a ‘real’ timer will flash up as well as a voice file telling you that you only have such and such time left.
* Illustrations of the ‘other reality’. Due to the screen being so small, and the design verses sound issue which I will go into again at a later date, there is only going to be a few drawn illustrations. Although I agree with this (The viewer can hardly run around and be staring at the screen at the same time) I would have preferred less movement and more design and narrative but that’s just me! Most people will be interested in the puzzles and not how it looks (How people disappoint me…) However going back to the main issue; these will be drawn from taking the surrounding landscape and changing the buildings and the way it looks. I need to research this and decide what is going to be in these drawings. Preferably I would take my inspiration from the narrative, but the narrative is not going to cover aspects like this. So for example we want an illustration of the docks while you are walking along. The river will be there and the walkway but everything else can change. Have being toying with a few ideas. Pirate ship on the river, boats coming and going (easy to animate) People walking past etc (Mostly using stop frame animation – Simple drawings put in a sequence to represent time passing) Anyway need to research this.
* Film aspects: we won’t be filming the people speaking for a while however I want to look into effects to make them blend in more with the illustrations. Was very very briefly toying with the idea of rotroscoping them, which would be great, but having already done this before, and nearly driving myself mad in the process, plus there simply isn’t enough time, this has being abandoned. But like I mentioned I would still like the style to be vaguely similar. The original idea was to have them filmed on a mobile phone. This was to give the viewer the sense of the urgency in which they were made and the general DIY feel of the game. I would still like to keep this idea- however make slight changes so it can fit in more with the general design. Possibly just a Victorian border or simply a ‘browning’ or sepia mask to keep the colour schemes generally the same.

This is where I have got to. All this work, apart from the illustrations will hopefully be resolved in the next few weeks. Once I have gathered rough SWF files of all my ideas I will try them out on the IPAQ and see how it all works.

I will report my findings.

Illustration style: experiments

The Hourglass:
Has been made into an animation, although is not time set as the only way I can figure out how to do that involves Java and I'm not convinced the hand held can accomidate this....


Illustration style of people:
I have currently being messing around with the levels of colour, in the next few days I will put them on the IPAQ and determine which ones are the easiest to see at night time, the effect of street lights of the screen (reflections etc).



Wednesday, January 10, 2007

LIFE A users manual: Georges Perec


The ultimate truth of jigsaw puzzles:

"Despite appearances, puzzling is not a solitary game: every move the puzzler makes, the puzzle maker has made before; every piece the puzzler picks up, and picks up again, and studies and strokes, every combination he tries, and tries a second time, every blunder and every insight, each hope and each discouragement have all been designed, calculated, and decided by the other."

A wonderful book and its made me cross. Such an amazing idea and although the idea is not a new one its still blows my mind! It uses the 'Knights Tour' which I did look at last year for my fairy tale project. I'm still at the moment looking into this as it is how I plan to write my interactive novel but more about that when I finish this MA. The Knight's Tour is a mathematical problem involving a knight on a chessboard. The knight is placed on the empty board and, moving according to the rules of chess, must visit each square exactly once. There are several billion solutions to the problem, of which about 122,000,000 have the knight finishing on a square from which it attacks the starting square. Such a tour is described as closed. Otherwise the tour is open Many variations on this topic have been studied by mathematicians, including Euler, over the centuries using:
  • differently sized boards
  • two-player games based on this idea
  • problems using slight variations on the way the knight moves.
The pattern made by a Knight's Tour has often been used as a literary constraint. The earliest instance of this is found in Rudrata's Kavyalankara written during the 9th century. (Wiki)
Obviously Alice through the looking glass is a fine example although I'm not sure if it would be under the rules of the knights tour. Alice is simply a chess game played out with narrative, I did recently recreate the game to see if it would work and it does. Another idea which I'm jelous of....And along the same lines as Alice, Italo Calvino The castle of crossed Destinies - My favourite of Calvinos (Apart from his short stories) Which is written using tarot cards. The narrator of the book is a traveler who arrives at an enchanted castle where all who enter are struck mute. After a silent dinner, the host spreads the Visconti-Sforza Tarot deck on the table and the guests lay out cards as a means of relating their adventures and telling their life stories. The Tavern of Crossed Destinies is Part 2 of this book. The device is the same - mute travelers who tell their stories with tarot cards, this time using the Tarot de Marseilles by Grimaud. Instead of laying their cards out in rows, they arrange them in irregular blocks with much overlap from one story to the next. As you can see there is scope for this to be made into an interactive narrative or at least use the idea of the cards - tarot or not tarot. Amazing.

Wednesday, December 06, 2006

The Hourglass

As the game is an hour long I have been thinking of how to show the players time running out. I came up with the hour glass - known as the hour glass as it was difficult to make one that could go on longer then an hour! Weirdly after a bit of research they were actually invented the same time as the mecanical clock. They can only be used as a basic means of telling the time. If you were to mark off five minutes on the hourglass each time you ran it, it would be slightly different. They can only tell you when the hour is up.

"Two technologies, one simple, one complex, running side by side -- the clock making a continuum of time, the hourglass segmenting it -- the clock speaking of timelessness, the hourglass showing us finality -- the clock evoking things celestial, the hourglass reminding us of base earth. They are Yin and Yang"


The hourglass, whose sands run out, was a thing of this base earth. It became a metaphor for the running-out-of-sands we all inevitably face. It became, and it remains, a universal symbol of death. This is interesting because I've been thinking of using one in the mechanical heart also. The persons life expectancy dependent on your class, IQ etc is all set when the heart is first placed inside the person. This can be terminated at any time - a simple flick of a switch and thats it your gone. Within our story the rebals have infiltrated there hearts they are no longer on the system.

Thursday, November 30, 2006

Drawing of the mechanical heart - research

Am currently trying to design the mechanical heart. I envisage cogs, hammers, levers pulleys some sort of clock work or maybe an hour glass? Victorian obviously! Would like to animate it in Flash to have as part of the introduction while the GPS is loading. Really need to have the narrative now to be able to start properly.... Designing when you don;t fully know what your designing for is tricky. But I can work on aspects of the animation which I know will be in there. Have started on the logo design as well as the general design. The characters will have to be done at a later date when the narrative is fully constructed and the relevant parts are split up into their relevant sections. How many drawings will there be? How many animations? How much written text? How much video? How much will need to be on one page or screen? Audio how much written text will images go with this also - will they be imperative the story or merely an extra should the viewer take the time to find them? Hidden parts? Extra bits of information for the more enquisative? The website? How much back information? The list is endless....