All Design Posts
Thursday, November 12th, 2009
Some designers will say that there is a limit to how far wireframes will go. Wireframes or sketches are good up until a point. They will cover structure and some static positioning of elements quite well. If the wireframing tool is good enough, it will even allow reuse of elements that will speed up the process.
Enter prototyping of rich internet applications. When lots of states begin emerging and changing, that’s where prototype eases the comprehensibility of work being shown. The scenario then is: why not extend wireframing or sketching with prototyping. Why not make embeddable prototypes for only those sections which need it. Could fluidia prototypes be called upon when necessary for sections of the interface that could be wirefamed in another application?
Scenario thinking here …
Posted in Sketches & Scenarios, by Jakub | 1 Comment »
Monday, November 9th, 2009
The ideea is to build the 3 elements – Login, Save and Login – in an uniform state once active / hover.
Jakub’s first sketch: the Login is active and background is applied around it; and the Save and Load are inactive, but once moved to Save the wrap background around Save needs to include Load too, although at Login it didn’t include Save or Load.
Thus, the ideea to create and wrap in background each element and to be the same regardless of what elements is chosen. The wrap background is expandable in height and width. The inactive elements are opacity 50% (example).
Posted by: Liv
Posted via email from fluidia’s posterous
Posted in Sketches & Scenarios, by Jakub | 2 Comments »
Tuesday, September 22nd, 2009
As obvious as it sounds, saving requires some form of authentication. Here is a more recent sketch to support saving and loading with authentication. Work can be saved as a web link, or stored locally. Similarly, work can be opened from a recent list of projects which have been worked on online, or a project can be opened from a user’s local computer.
The idea is to delay the login or registration beyond saving and loading. Hence, users would be able to save and load without having to create an account. In this scenario, if a user has not logged in and saved work, a cookie should keep the session alive until he or she comes back in the future to resume work (or to create an account).
Posted in Sketches & Scenarios, with the following tags: ui_saving, by Jakub | No Comments »
Friday, September 4th, 2009
Here is a second attempt at the Experience Threads functionality. I’m also thinking of simply calling it “Scenarios” as that might be a term with which more people might be comfortable with. In this revision, the idea was to:
- integrate the experience threads higher into the top bar, away from overlapping the workspace
- create controls which would allow users to move through the scenario more visibly (arrow buttons and arrow keys)
- make the experience threads / scenario tool be bigger than the rest of the canvas drawing tool (take the scenario tool away from the left tool bar and move it to the top)
Another idea which this sketch explores is using icon size to represent how big each scenario or thread is. This can be seen in the experience thread / scenario overview page. So, the more snapshots or items a thread has, the larger the icon.
Posted in Sketches & Scenarios, with the following tags: ui_experiencethreads, by Jakub | No Comments »
Thursday, May 21st, 2009
Here is a new idea for how the master edit mode could operate based on the results of the last user testing. Basically the idea is to really differentiate the master edit mode from the standard and default edit as instance mode. The master edit mode also could require an explicit action and would highlight everything surrounding the selected object as a blue and transparent overlay. After returning from editing an object as a master back to instance edit mode, the inheritance controllers could grab the user’s attention by highlighting.
Posted in Sketches & Scenarios, with the following tags: ui_editmode, by Jakub | No Comments »
Thursday, May 21st, 2009
The workspace in design mode has to make certain information visible to the designer. Here are a few very rough ideas on what and how fluidIA could show these in the workspace area.
Posted in Sketches & Scenarios, with the following tags: ui_workspace, by Jakub | No Comments »
Thursday, May 21st, 2009
Often objects begin stacking on top of eachother and get in the way of the visibility of the elements underneath. What if there was a way to see through all objects on key press. What if invisibly set elements could also appear on demand?
Posted in Sketches & Scenarios, with the following tags: ui_layercontrol, by Jakub | 1 Comment »
Thursday, May 21st, 2009
FluidIA is about flexibility. FluidIA objects can become guides or scaffolding like objects which can be toggled or replaced by either images or real code. Sketching on paper is still more flexible than drawing of any kind on the computer. What if a fluidIA object could be replaced or toggled into an imported sketch for those designers who love the pencil? Or, what if later on in the process a visual designer replaces a fluidIA object with a detailed mockup?
Similarly, fluidIA object do not generate server ready code, and some things are best done with HTML, CSS and real programming. For this reason, fluidIA objects should allow for switching into the third mode that would enable a developer to do his/her magic such as data binding, CSS layouts, or highly complex event logic.
Posted in Sketches & Scenarios, with the following tags: ui_objectrefinement, by Jakub | No Comments »
Thursday, May 21st, 2009
Experience threads, flows, or user stories enable designers to represent bigger ideas about various forms of user needs that the interface ought to support. It is a form of abstraction of requirements but also a way of envisioning in the form of scenarios. More so, designers should be allowed to own and interpret requirements which this feature allows for. Here I am referring to use representation as threads, as to step away from the misleading, inflexible and superficial idea that use happens in a predictable and linear way. Instead I would like to offer up the possibility to allow for complex threading of use representation.
More so, after interviewing a few designers, it was found that there is a definite preference for presenting wireframes as opposed to just sharing them (which results in important ideas being misunderstood or ignored). Hence, during presentation mode, experience threads could also be used as to guide the presentation with the stories the interface supports (visible in alternative G). Also, during presentation mode, comments could be captured about the feedback gathered which is visible in alternative (I).
[Updated June 10]. The new ideas starting from (Q) and on, explore the possibility of creating experience threads by means of taking screen snapshots of the interface (and various object states). More so, these screen snapshots can be intertwined with representations of user activity to tell rich and visible stories of interaction that can be used to fuel the presentation mode.
Posted in Sketches & Scenarios, with the following tags: ui_experiencethreads, by Jakub | 1 Comment »
Tuesday, May 12th, 2009
How could users save their work using fluidIA? These few sketches play off on the idea that saving of the work could happen in at least two ways. Users could potentially be able to save their work as a web link URL, allowing easier sharing. On the other hand, users who feel more secure about their data being stored locally, could do so by means of the second saving option. This sketch also explores the idea of saving data locally by means of a Firefox plugin. Perhaps this same functionality could also be achieved by means of Google Gears or an Adobe AIR application. This “save as URL” sketch also suggest that the possible name of the URL would be checked in real time for availability.
Posted in Sketches & Scenarios, with the following tags: ui_saving, by Jakub | No Comments »
