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?
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).
Interested to get involved with an open source project? We are actively seeking a PHP developer to help build a web services API. Yes, Alex is still here integrating the backend code with the front end, but we thought one more pair of eyes would be nice. We are creating PHP functions to serve the requests from the fluidIA jQuery based client. A few hours each week is all it takes.
I’ve been meaning to make sketch or concept submissions a bit easier for a while now. Finally I managed to link a posterous.com account to the Sketches & Scenarios category which will allow anyone to submit fluidIA ideas in the form of text scenarios, images, video, audio, etc. I’ve explained how to submit such content right here, along with an appropriate email being listed visibly. The email is an image to hopefully minimize spam. Currently I have to moderate all posts, but if I see that you are a frequent contributor, I can also add you to the white list.
Secondly, I’ve also reorganized the RSS Feeds & Update section. There are now two core RSS feeds. One light one for general announcements, and another one with every blog category for people interested in the design and development process along with some rough ideas.
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).
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.
Something just stirred over at the stage. This new version is pretty much what I tested with last week. The version contains the experience threads idea (which as indicated by the user testing still needs quite some work). The other thing which I believe I fixed finally is the interaction of copying and pasting. Items should now paste appropriately for the two main copy modes “New Master Object” and “Instance of Master”.
Next week I’ll also be flying over to the Netherlands for my graduate presentation. Uhm… what’s next? I will be looking out for UI and UX type of work on a freelance basis, and will plan to continue fluidIA for at least 2 days a week. So the project is not going away anywhere. Sometime in August I will also plan a vacation, so the summer and the graduation has only slowed down the project temporarily. Looking forward to continuing working on this with you all.
Another wave of four evaluation sessions finished. The full document with more detailed observations can be grabbed from here. The video of the third session is also available below (click on HD for higher quality):
The biggest findings in the third testing cycle included the following:
State and Idea controllers. In this iteration, users have become less informed as to how to create new states and ideas. The footer has decreased the visibility of the actionable instructions (holding X or Z) which users found more difficult to identify. Once pointed to the HOLD interactions, users were able to create and edit states and ideas. A second problem for states was that the state switching buttons still were not differentiate enough in terms of their selected and unselected states.
Experience Threads. Most users really felt the feature was interesting; however there were a few problems. For one, after completing a thread, users felt a need for closure and to play back or test a created thread – a feature which was missing. Secondly, users had some hard time finding the “snapshot” tool which was hidden under a sub menu. Thirdly, conceptually, experience threads felt to users as if they were bigger than the existing tools, and should be brought out more into a separate position or location. Fourthly, due to a lack of feedback, users did not really know in which thread they were currently in.
Selection. Any currently selected item that is selected has diminished visually. As a result of not knowing clearly what is selected, more users have deleted items unexpectedly as well as tried selecting items which were already selected. The visual indication of currently selected items (and its sub child items) should be made stronger.
Instance and Master. Even though now the master edit mode requires an explicit toggle, some users still expressed confusion as to which edit mode they were actually in. A stronger indication is required in the next iteration. After the introduction of this explicit Master Edit Mode, users still expressed a need to get out of this mode in with more certainty that their changes were being saved.
Inheritance. Although the idea of inheritance was understood by users. To most it was still not identified and required guidance to be actually found.
Auto grouping. Most users understand the parent – child relationship (“drawing inside” feature), however they do not know how to adjust or change that relationship. For example, users expressed the desire to move an object into a different object (thus changing the
Thanks to Avi, Dana, Verne and Mehdi for participating!
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.
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.
