Archive for the 'iido' Category

iido leaf transformations

A little later than I hoped but I’ve finally got round to recording a short demo of the progress I have made on the iido project. The demo shows basic implementations of the four core transformations possible for leaf widgets,

  • movement,
  • rotation,
  • resizing,
  • and z-level stacking.

I apologise in advance for the quality of the video, I will look to provide higher quality alternatives in future as youtube tends to reduce the quality far to much for my purpose. Oh, and I’m really not sure why, but my screen grabber has tinged everything green.

There is still a lot of refinement to do, but I’m hoping to have a usable demo available in the next few weeks to allow people to experience leaf widgets for themselves and provide me with some initial feedback.

The next stage of development is to change the cursor when the user is transforming a widget to help guide them, simple as it sounds, I made a complete hash of my first attempt. After that I’m going to put in place a few helper actions on the context menu, such as “Straighten” to reset the angle of a leaf widget, and also look into providing the ability to change the pivot around which a leaf rotates.

You may have noticed that the transformation system has changed quite a bit since my first proposal, and these changes have come about through trial and error to see what feels natural to me, a better assessment can be made once I have feedback from those who download the first available demo.

Advertisements

Up, down & famfamfam…

So things are going a little slower than I’d like with the development of the prototype for iido, still I managed a concerted effort today to make a start.

The first challenge was to update my Qt and PyQt installations, which I have to say (if memory serves me correct) with version 4.4+ is a much easier task than with previous versions. One gottcha you might want to watch out for (possibly Windows OS specific) is forgetting to uninstall the previous version of Qt, this can cause PyQt to try and access the wrong QtCore4.ddl and then your application wont run. Thankfully the solution is simple, just uninstall the previous version of Qt and your set.

Back on subject, once my system was up-to-date I was able to make a reasonable amount of progress. In these early stages I’m still putting inplace quite a bit of framework to support the management of widgets, however with some basic widgets visible and draggable (just using the Qt draggable flag at the moment), I realised that I hadn’t considered the overlapping/z-index of widgets.

To solve this I am putting in place a simple stack style transformation that allows the user to (see the screen-shot),

  • Bring the widget to the front
  • Send the widget to the back
  • Bring the widget up one Z position
  • Send the widget down one Z position

Early screen-shot of the prototype iido application

However, there are a number of issues still to be resolved,

  • The Z position is relevant to all widgets so it might take several clicks for a user to move a widget above a desired widget
  • When a user wishes to transform a widget using the transformation regions, the region they require maybe hidden, to resolve this the user would have to move the widget so that the region was visible.

I think the Z position issue can be resolved by building in another couple of transformation options that allow the user to move the widget in front or behind a specific widget (this may eliminate the need for the up/down one option). There might also be some merit in allowing users to specify a specific Z position in which case we would need to make the Z position of all widgets visible. As for hidden transformation regions I am open to suggestions, though I think I may need to have a function model before a decision can be made.

Finally I’d like to credit the famfamfam icon set which I am using whilst developing iido, this is a professional quality set of icons available from www.famfamfam.com under the creative commons license (http://creativecommons.org/licenses/by/3.0). Producing icons is a hugely time consuming process and my sincere thanks goes to the creator Mark James for his efforts and generosity.

A new kind of widget, a leaf…

One of the major areas of development in the iido application will be the custom interface. Though typically in designing a user interface I would try to avoid the creation of non-standard (and therefore non-familiar) interface components, because of the interactive requirements of the iido application some custom components are inevitable.

The first of these components being examined is the leaf widget, which is actual a sort of cross between a standard window and a general purpose flow diagram box. The reasons for calling this new hybrid widget a leaf is that,

  • it represents a leaf of paper (all be it a feature rich leaf of paper),
  • it floats on the interface surface (can be thrown and spun),
  • it can be linked to other leaves via one or more branch (ok, I’m pushing the anologies here, but you get the idea).

Those of you who’ve had the (I’ll say…) experience of working with me will be use to me trying to over add meaning to names, but it’s only a working title for the time being so indulge me.

At the current time what Andy and I are looking at prototyping is user interaction with widgets, and in the short-term we’re concentrating on transformation, the following image provides an overview of the how a user might be able to move, rotate and resize a leaf widget.

Transformation of leaf widgets

The leaf widget will provide move, rotate and resize functionality all via a single mouse button, regions around the border of the leaf will provide the user with access to the various transformations. Regions will only appear once the user mouses over the leaf widget, and will (as can be seen in the image) be highlighted (including a guide) once they are activated by a mouse click.

I’m going to be putting together a basic prototype of the leaf widget in Python and Qt over the next few weeks, the source will be made available to those who are interested in running it, I’ll also provide a video for those less adventurous.

Again, all feedback and ideas greatly appreciated. It’s been really good to hear what people see as requirements for such an application, and I’d really like to know what people think of the non-standard transfomation idea.

First glimpses…

As promised I’ve uploading a visual of how the iido interface might look. The visual is simplified (only showing 2 lists and a single connection), but it’s a starting point for discussion. In actual fact over the last few weeks Andy and I have made several design descisions based on simple prototypes, and a more upto date version of the interface (including more visuals) will be discussed in the next blog, which is concerned with user/object interactions in particular transformations.

So to the visual…

iido interface first visual

A couple of things about the visual,

  • No tree-view association, lists can be linked in parent>child or in sibling format. However, these relationships are then shown by lines, not necessarily by position.
  • Lists are shown in a custom looking window, the window (which I call a Leaf widget) is currently the core subject of my prototyping, the idea is these can be thrown (moved), spun (rotated), resized, and minimized – the look and feel of these has changed a bit over several revisions.
  • The little colour icon on the bottom toolbar indicates that it will be possible to style individual lists, either with preset styles or individually (the resize icon should be ignored as this is something that has changed in the new prototype).
  • The visual only shows two linked to-do lists, the plan is that a Leaf may contain any sort of content, images, a list of contacts, flow digrams, spreadsheets…

So hopefully this will spark something in you guys, even if it’s abject hatred, let me have it all.

Initial thoughts…

iido is a graphical to-do list application, or at least that’s the intention at the moment (these things have a habit of becoming more).

As a software developer for over a decade now, one of the most useful skills I’ve aquired (or put another way become better at) is being able to organize my projects and tasks. Any developer who has ever worked on a medium to large project will have used some form of project/task management.

There is a labyrinth of good project management tools out there, both commercial and open-source, many of which specialise in specific areas of project management.

Even though there are all these tools available, the tool I use everyday is the mighty pen & paper (or if I’m feeling patient a plain text document and Dia). Why? Well, from a personal stand point it’s purely down to speed, freedom and convenience.

When I first started to think about writing a to-do list application, I first wrote down a list of things that I like about using a pen & paper.

  • Speed – It’s not just that I can write faster using a pen (my writing is barely legiable to me), it’s that I can write, draw and visually associate various items on one or more pieces of paper, quickly.
  • Freedom – All of us have a different ways of documenting our planning process, alot of the time this means drawing (rough) flow diagrams, tearing or folding paper, writing at an angle, etc.
  • Portability – I can pick up a piece of paper, tear off what I want, put it in my back pocket and take it with me.
  • Collaboration – Whenever I discuss an idea with a colleague I use a piece of paper to explain my idea, and usually in turn they will use the paper to amend my work, and so on and so forth.
  • Unstructured associations – I often write down related information on a piece of paper like, contact information, reminders, ideas, etc.
  • Unobtrusive – My favourate thing about a piece of paper is I can look at it instantly (no load up time), without switching my application.

Obviously there are also a lot of things to dislike about pen & paper, lack of consitency, poor accessibility for other users, no backup or version control systems, etc. This project is about trying to produce an application I’ll want to use instead of pen & paper, and in doing so provide the benifits of an electonic format without (where possible) comprimising on the benifits of paper.

Over the course of the next few weeks I plan to discuss and present ideas for the project on this blog, I’d much appreciate any feedback people have. Currently the team for this project will be myself and my father Andrew – and hopefully a little help from some of the talented friends I’ve been lucky enough to make over the last decade in software.