FinalPrototype-Group:4Corners

From CS160 User Interfaces Fa06

Jump to: navigation, search

[edit]

Final Report

[edit]

Team Members and Roles

Tabassum Khan
- Coding prototype, presentation demo.
Maksim Lirov
- Coding prototype.
Ramy Ghabrial
- Writing up, proofreading wiki; presentation.
Chen Chang
- Writing up wiki, presentation slides.

[edit]

Problem and solution overview

The concept behind our Anoto-enchanced blogging application is to target casual personal bloggers who wish to share information about their lives and experiences with friends. We seek to address the fact that people are inherently accustomed to writing on paper (like old fashioned diaries for example) and are prone to forgetting their ideas if they are not jotted down on the spot. Many people have reduced their blogging frequency over time and for various reasons are not able to blog as often as they would like to. The main problem is essentially one of available time, as bloggers often need to take a chunk of time out of their busy schedules to sit down at a computer terminal to draft or publish an entry. Convenience and portability are the main issues to be resolved, and our solution seeks to address these facets by providing an easily accessible interface using the Anoto system for jotting down ideas anytime, anywhere. The inherent portability of digital pens and paper allow everything to be written down when inspiration strikes, then get uploaded to a computer once the blogger gets home, after which he can make use of editing functionalities and configuration options.

[edit]

Target user group

Our target group consisted of casual personal bloggers. These are people who maintain blogs of personal nature, talking about events in their day or things that are on their mind, and typically update their blog once a week. Our reasons for choosing this specific group of bloggers are: a) utility -- there are many such bloggers to be found; b) background knowledge -- these bloggers are already computer savvy enough to know how to create and write in a blog, and might easily be made aware of the benefits that our interface provides over current blogging systems; and c) narrowed focus -- as opposed to designing a generalized system for blogging in general, we decided to focus on particular aspect of blogging and make it as efficient and user-friendly as possible.

[edit]

Tasks

The following are the 3 tasks (easy, medium and hard) we chose to test our interface:

Easy Task - Create and Modify a blog entry

The goal of this task was to create a blog entry on the paper UI of "4Corners Blog" application and later modify the same entry on the provided graphical user interface. We chose this as the easy task because it provides an introduction to what we expect our users to do without difficulty pretty much every time they fire up our interface. The following steps are needed to accomplish the goal of this task:
1. write a blog entry on the paper UI and check save as draft box.
2. dock the pen in the cradle.
3. fire up 4Corners application; a window will appear displaying the drafts tab which will have the most recent entry on the top of the page with date stamp.
4. click on EDIT button
5. A screen will appear with the entry for preview puposes and a bunck of other buttons, such as "Background Color" button, "ink Color" button and "Stroke Width" button. 6. The user can either click on one of the buttons and modify the blog entry or right click on the blog entry
7. In case of right click, a drop down will appear with a list of options
9. click PUBLISH or SAVE

Medium Task - Change the default appearance of the entire blog

The goal of this task was to change the default appearance of the entire blog such as Background color, ink color and stroke width. We chose this as the medium task because it provides a lesser used and slightly more complex functionality to our users than editing just one entry. The following steps are needed in order to accomplish the goal of this task:
1. Click on the SETTINGS tab; a screen will appear with four options: Manage Account, Change Default Appearances, Security Settings and Upload pictures
2. select the "Change Defualt Appearances" option; a screen will appear with the following options: Background Color, Ink Color and Stroke Width. This screen will also have a preview box where the most recent published blog entry will be displayed. The purpose of this preview box is to provide the user with an instant feedback on the options being selected. The blog entry in the preview box will change based on the option selected by the user.
3. select one of the three options; as mentioned earlier the appearance of the blog entry in the preview box will change.
4. click on SAVE; the user will be taken to the "YOUR BLOG" page. The appearance of this page has been updated in accordance with the selections made my the user.

Hard Task - Insert an image into a draft entry

The goal of this task is to create a blog entry leaving some enpty space on the upper half of the blog space and later add an image to this blog entry using 4Corners application. We chose this task because it provides the most specific and intricate functionality we expect our users to make use of. The following steps are needed in order to accomplish the goal of this task:
1. write a blog entry using the digital pen, drawing a reasonably large box where you want to insert an image, and check save as draft.
2. dock the pen.
3. fire up 4Corners application; a window will appear displaying the drafts tab which will have the most recent entry on the top of the page with date stamp; click on My Drafts to see your entry.
4. there is a placeholder where the image will be placed; click on EDIT then click on the placeholder.
5. a pop-up to select image will appear.
6. select an image file from the machine
7. click on the OK tab then SAVE button to save the selection; the selected image will appear on the blog entry.
8. select the PUBLISH button.

[edit]

Design Evolution

There were many stages in our project's design. This section provides a rough timeline of the different versions of our prototype and how they evolved and differed from each other. Our project implementation can be roughly divided into 4 checkpoints: Initial Sketches, Lo-Fi Testing, Initial Interactive Prototype, Pilot Usability Prototype and Final Prototype.

[edit]

Initial sketches (Contextual Inquiry and Task Analysis)

First, here is the basic foundation we came up with in initial sketches, so that we can more easily track the changes we implemented in later stages.

Our interface as defined by our initial sketches consisted of a menu with 4 main tabs:

Your Blog - This is the default view of the application. It displays all the blog entries published by the user with date and time stamp headings. All the entries will be sorted by date and time. Under each blog entry, there will be a link to the comments made by other bloggers on the user's blog entry. The user can view the comments by clicking on the link and the interface will expand in order to display them. Beside the comments link, there will be an option to delete the blog entry from the blog. User can remove an entry from the blog by simply selecting the delete button.
Save Drafts - The drafts tab of the interface shows a listing of all the entries that were entered with the Anoto pen and were not marked for immediate publishing. The listing of entries is sorted by date headings with the full entries underneath each heading. Immediately underneath each draft entry are two buttons - Edit and Publish. The Edit button allows for the manipulation of the digital pen strokes of the entry as well as the customization of the entry background and stroke parameters (thickness, color). The Publish button publishes the particular entry to the blog. As soon as a draft entry is chosen for publishing, it is moved from the drafts list under the Drafts Tab to the submitted entry list under the Your Blog tab.
Subscriptions - Here the user will be provided with an option to add the blog names of his/her friends. The added blog names will be stored in a list of subscriptions that will be owned by the user. The user will also have the capability of updating this list. When the subscription tab is selected, the interface will display random blog entries from amongst the user's list of friends. The list will be displayed on the interface, which the user can use to select a friend to view the blog entries published only under that particular blog name. These blog entries will be sorted by time-stamp. There will be a "Post Comment" button beside each blog entry. The user can select this button to post comments to his/her friends blog. Here is what the subscriptions tab should look like:

Settings - The settings tab presents options to customize aspects of the blog entries. Options in this tab are - Manage Account, Change default appearance, Security settings, and Upload user pics. The "Manage Account" option allows for entry of a nickname and profile for the blog. The "Change default appearance" option presents settings to customize the ink color, stroke width, and background color with a preview window underneath. The security settings allow for selection of which parties are allowed to view the blog entries. These security settings are in accordance to the settings available in the blog from the particular blog service. Finally, the "Upload user pics" option allows for the selection and uploading of an image from the user's computer.

Here is how we initially envisioned the user interacting with our interface.

[edit]

Storyboards

[edit]

Changes made for Lo-fi testing (paper prototype)

The next stage of our project involved creating a lo-fi prototype. The biggest change to our initial sketches which we made for our lo-fi prototype can be seen below:

As you can see, we changed the "subscriptions" tab to a more intuitive "Friends" tab. This was because "subscriptions" was a quasi-technical term and we were not sure that our users would understand what we meant by it.

Aside from that, our lo-fi prototype was essentially a direct translation of our initial sketches. We fleshed out our initial sketches were appropriate, but the basic concepts remained the same. Here are some of the things we had to add to our prototype that were not detailed in our initial sketches:

Anoto interface: This is our paper UI. The user writes on the paper and ticks either the save as draft or publish box. Should he choose to publish, our program will take care of all the details so that he does not have to look at a screen. If the user edits the physical paper, the changes are automatically reflected in the GUI the next time the pen syncs up with the computer.

Odds and Ends: The top row of this picture shows assorted context menus, in order from left to right: the right click menu when editing an entry, the choose background color menu, the choose ink color menu, and the choose stroke width menu. These will offer more choices in the final program.

[edit]

Changes made for initial interactive prototype

After we were done creating a tangible prototype, we then had to transform it into an interactive computer prototype. Here are the changes we made from our cumulative interface up to the lo-fi prototype, in order to create the interactive prototype. We based these changes on our lo-fi testing.

Tabs labeled "My Blog", "My Drafts", "My Friends Blogs", and "My Settings"

Through our low-fidelity prototyping and user testing, we found out that our users had some trouble in identifying what the tabs represented and what would be behind them once clicked on. To erase ambiguity, we decided to change all the tabs by adding the word "My" in front of their existing labels. We think that this change brings a more intimate feeling between the user and his or her blog as it clearly makes sure that the user understands he or she is under full control of all options. The stronger sense of ownership could make the user feel more at ease and less reluctant to play around with the possible customization options. Additionally, the "My Friends" label created some confusion as to whether it was for people who subscribed to your blog (wrong) or for people to whose blogs you subscribed (correct), so we changed that to "My Friends Blogs".

Draw a Box Frame to Denote Area to Embed Image

In observing our users during testing of our third task, we observed that they had some difficulty in comprehending the directions in order to properly embed an image into their blog entry. The hotspot gesture did not prove to be successful for users trying it out for the very first time as they were lost and confused as to how to select the image and how to follow the instructions. In order to make this task easier, we propose the solution of having the user draw the entire box where he or she desired to have the image inserted. Then after the pen data is uploaded to the computer, the user can easily attach an image with the click of a button as the on screen display will show an obvious "click here to insert image" text label inside the area where the user drew the box frame.

Added underlines under the links in the friends list under the Friends tab

User testing revealed slight flaws in the content behind our "Friends" tab. In particular, it raised questions as to what kind of functionality it presented and what kind of links were clickable. We think that by making it absolutely obvious what links are clickable, it also resolves the problems with questionable content on the page. In our modified interface design, we are adding underlines to all the names of the user's friends in the left column to make sure the user understands that they are clickable. Even if the user was still puzzled at this point, he or she could quickly experiment by clicking on the links on the page and then figure out the intended functionality. We don't even need to worry about graceful error handling as all the links are safe to click on and return in a circular fashion (i.e. you click on the name of a friend and then you are still on the exact same page with the only difference being the entries displayed are for that particular friend, left column remains unchanged and you can click on another friend's name).

Added mouse listener to the Friends tab

In our interactive prototype while experimenting around with Swing and the code to drive the GUI, we decided to add a mouse listener under the Friends tab to make the list of friends of the user easier to manage. Now when the user moves the mouse arrow on top of one of the names in the list, the arrow will change to a hand symbol which make it obvious to the user that the names are clickable.

Tabs all contain specific mouse-over text

In addition to changing all the tabs to add the word "My" in front of their existing labels, we opted for an alternative resolution to make the tabs representation as clear as possible. We decided to add mouse-over text to each of the tabs so that the user could get a description of what lies behind the tab before clicking on it simply by hovering the mouse over the tab. The mouse-over text is as follows: My Blog tab reads "My published blog entries", My Drafts tab reads "My unpublished blog entries", My Friends Blogs reads "Most recent blog entries from my friends blogs", My Settings reads "Customize my blog - account info, appearance, security, pictures". This change should resolve any ambiguities the user may have regarding the tabs and provide a greater comfort level in manipulating the blog interface.

Allow for GUI insertion of pictures

This isn't so much a change as it is an addition to functionality in our image insertion task. Before we only supported the ability to embed an image through designating an area on the paper UI and then selecting the actual picture on the computer itself once the pen was docked and data transferred. We decided to keep this paper UI portion the same but added the ability for the user to embed an image directly in the GUI itself. This adds more options for the user and is useful in the event the user intended to attach a picture but forgot about allocating an area on the paper.

[edit]

Changes made for Pilot Usability prototype

Once we were done creating the groundwork for our interactive prototype, we continued modifying and improving it as much as we could until we performed pilot usability testing. Here are some of the changes we made (aside from bug fixes) to our interactive prototype before letting our users test it.

Changed the vertical scroll bar to be inside the My Blog, My Drafts and editing tabs. In our original prototype, the vertical scroll bar was independent of the tabs, and could be used to view more than one entry at a time in My Blog and My Drafts, but served no other real purpose. This created problems when editing because clicking on edit for the last entry meant you had to scroll back up to see the editing panel. It was also a problem because the main tabs themselves scrolled out of view when you moved the scroll bar thumb down, and this meant you had to scroll back up to access different tabs. We solved all these problems by making the scroll bar part of the My Drafts and My Blog panels themselves. In other words the horizontal scroll bar does not exist, and the vertical scroll bar only appears inside the tabbed pane when needed, and does not affect the position of the tabs themselves when used.

Removed the horizontal scroll bar. This scroll bar was a product of inefficiently set panel sizes and was never actually used, so we took it out. It also suffered from the same problems as the vertical scroll bar, but these are no longer an issue.

Here you can see both the abovementioned changes. Notice that the scrollbar is not at the top but the four main tabs remain visible.

Added delete buttons to entries in My Drafts. This was not a requested feature but something we realized might nevertheless be important to our users after we submitted our initial prototype. Simply, we inserted buttons under all entries in My Drafts to allow for the deletion of entries, so that users could discard unfinished drafts if they lost interest in, or decided against, eventually publishing them. These entries would subsequently disappear, to be replaced by the next most recent entries.

Notice the newly added delete button, described above.

Added icons to the four main tabs. We added little unique icons to the My Blog, My Drafts, My Friends and My Settings tabs. These icons allow for easier visualization and distinction between the separate tabs, so that the user might more quickly grow accustomed to their look and select tabs based on location and icon rather than reading them each time. Additionally, they make our interface slightly less plain and more pleasing to the eye, which reduces user frustration.

Notice the different icons on each tab.

Fixed miscellaneous layout issues. These were mostly positioning of buttons and popups. There was one dialog popup in our interactive prototype that appeared in the bottom right of the interface, slightly obstructed by the window's edge, so that it had to be dragged back up to click on its OK button and dismiss it. We fixed this, among other minor layout problems.

User can no longer click on other tabs while editing. This was perhaps the worst bug in our initial prototype. While editing a draft, a user could click on other tabs before saving or canceling. This would sometimes cause the program to act in unexpected ways. To rectify this, we enforced tab positions while editing and removed the option of clicking on other tabs. To make this clear to the user, the icons on other tabs are greyed out while the user is editing an entry in My Drafts or My Blog.

Notice that the other icons are greyed out. Clicking on those tabs has no effect, because the user is currently editing an entry.

[edit]

Changes made for Final Prototype

Taking the feedback from our user testings of our pilot usability study into account, our work was cut out for us and we made a final push in making modifications and improvements to further enhance our blogging interface. The following are the changes we felt necessary to make:

Added icons to tabs, icons to all buttons in edit pane, icons to buttons in My Settings.

In our pilot usability study, we decided to add small pictorial icons to the My Blog, My Drafts, My Friends, and My Settings tabs. To follow up with this process, we decided to further add icons to all the buttons in the edit pane as well as to all the buttons under the My Settings tab. These icons allow for easier visualization and distinction between the separate tabs and buttons so that the user might be able to quickly get accustomed to the look and select tabs based on location rather than reading the text every time. Because we took the time to choose appropriate icons fitting for each tab or button, we feel that the icons are excellent eye candy and further enhances the overall look and feel of our blogging interface. At the very least, the icons reduce the possibility of a dull and boring interface and can hopefully attract more users.

(Screenshot 1)

Moved the add picture button from the My Blog and My Drafts tabs to the Edit panel.

Rather than have the button to insert a picture at both the My Blog and My Drafts tabs, we decided to move this button to the Edit panel. We feel that this change is necessary because inserting a picture is a form of editing whether it be a draft entry or an already published entry. Also, through the process of inserting a picture, the user may suddenly have the desire to change some other settings such as colors or to add a text caption regarding the picture or especially move the picture around. This would have been difficult to do in the old implementation as the user would clumsily have to first insert the picture and then edit the respective entry afterwards. Now, this is a streamlined process that can easily be done in conjunction and the user could then either save the changes or back out and cancel as desired.

(Screenshot 2)

Added the Insert Text button to the Edit panel, added the Insert Picture function to the right-click edit menu.

Through our pilot usability testing, our subjects suggested that we make the functionality of inserting text more obvious; at the time it was only available through a "hidden" right-click menu. We have responded to critiques by adding a button in plain sight on the edit panel for the user to inset text once clicked on. Also, we added the insert picture functionality to the right-click menu so it is available as a button on the edit panel as well as the drop-down menu. Having commonly used features in more than one place greatly reduces frustration by users when they have to deeply search to find a often used mechanism.

(Screenshot 3)

Added text instructions on Edit panel to make the right-click functionality clear.

This was another major concern from our pilot usability testing as all three test subjects were surprised about the right-click functionality that appeared to be "hidden". This drop-down menu provided many more options for the blogger and thus would be a shame if skipped over. We decided to correct this by adding text instructions on the edit panel to make the available functionality blatantly obvious.

(Screenshot 4)

Rearranged the buttons in the edit panel (lined them up).

Our blogging interface had a lot of plain space that could be reduced to a minimum as a user suggested during testing. Elimination of wasted space has the obvious benefit of less scrolling around to read through the blog and we agreed about the necessity of doing so. To fix the issue, we rearranged the buttons in the editing panel by lining them up in a straight horizontal line. This is much improved from our pilot usability study and interactive prototype from before as we had the buttons lined up vertically which consequently took up much more space by default and caused the user to scroll much more to read.

(Screenshot 5)

Image Insertion Hotspot from the paper UI to the draft entry in the application.

The user draws a square or rectangle or similar shape on the paper UI, and then in the application it is replaced by a placeholder which contains hover text with instructions and an icon signifying that a picture goes there. In Edit mode, the user can click on the placeholder and a file selection window appears to allow the choosing of an image to display.

(Screenshot 6)

(Screenshot 7)

(Screenshot 8)

(Screenshot 9)

Component placement and drag and drop.

This is a vast improvement with regards to our pilot usability study as our components resulted in predefined and set locations before. For instance, the user's chosen inserted image and/or inserted text always appeared in the top middle of the blog entry. Obviously this was not very fluid and all our users brought up the suggestion to make these components dynamic and flexible much like how most things are draggable and droppable in windows. We took these suggestions to heart and now the user is able to drag a picture or text box (with typed text) across the blog entry to any location that he/she desires.

(Screenshot 10)

(Screenshot 11)

(Screenshot 12)

(Screenshot 13)

Any number of components can be added to blog entries.

The user can now add as many pictures and text boxes as he/she desires. Before only one picture or text box each could be added and all components that were inserted after the first one did not display properly or were not transferred between entries correctly.

(Screenshot 14)

Added stroke width implementation.

Stroke width was a part of our original functionality during our initial brainstorming sections at the start of the project. However, we weren't able to implement it interactively until now. The user can now set the stroke width for the whole blog entry. In the screenshots below, the user picked a 3.0 thickness.

(Screenshot 15)

(Screenshot 16)

Added hyperlink functionality.

This was a bonus feature we decided to take on ourselves after the pilot usability study although none of our test participants requested such an aspect. Hyperlink functionality has been added to our blogging interface and this gives the user extended freedom in what he or she is able to have in a given blog entry. Now the user can link a webpage from the world wide web as an embedded hyperlink inside an entry by simply typing in a webpage address when inserting text. This is a very practical addition to our interface as the internet is so ubiquitous these days that one would figure nearly everything links to it in some shape or form.

(Screenshot 17)

[edit]

Explain which evaluation technique was most valuable to your prototypes usability and why?

We felt that all the evaluation techniques introduced in this course (contextual inquiry, low-fidelity prototype, interactive prototype, pilot usability study) were each uniquely helpful in their own right and all were excellent experiences for our team to enhance our user interface. To choose the most valuable evaluation technique, we feel that the low-fidelity prototype and user testing helped our project design the most. We felt that the paper prototyping was extremely helpful in revealing the flaws within our ideas even before settling down to program and code our interactive prototype. The paper prototyping was the first major design of our intended application, as before that we didn't have the complete picture laid out in front of us in terms of look and feel as well as function. Through the process of designing the paper prototype, we were able to think outside of the box and try to be in the shoes of the user to decide the appropriate actions with the design. The low-fidelity stage of the design cycle was also the time when we smoothed out the main functionality details and this laid the solid foundation for our first interactive prototype to be coded in java at a later time. In having a comprehensive low-fidelity prototype, it also simplified our lives throughout the rest of the semester as it made the interactive prototype much easier (we essentially needed to translate what we had on paper into computer code). To have a solid prototype, there must be user feedback involved and we were never short in that department. All the important points our users pointed out during testing were noted (i.e. task instructions weren't clear enough) and they consequently helped us fix our biggest usability issues at the time. Since we were working with traditional paper, making changes was very easy eg. we were able to change the name of one of our representative tasks on the fly by redrawing one of the index cards. Furthermore, the paper prototyping was our first chance at getting and contacting some real users for testing and it allowed our team to generate a better understanding of the needs of our target users. Finally, even theoretically speaking, our lo-fi prototype was the most important one simply by virtue of being our earliest tangible design implementation. The number of ideas, both under consideration and weeded out as a result of testing, were greatest for the earlier design implementations of our project, as shown in this slide from the Aug 30th lecture:

[edit]

Final Interface

[edit]

Final UI Design

Our final UI design depicts an evolution through the design cycle beginning with our low-fidelity prototype mock-ups all the way through the changes built upon user suggestions from our pilot usability study. If interested, one can go through the 4Corners project groups page to see the progression: task analysis and contextual inquiry --> low-fidelity prototype --> interactive prototype --> pilot usability study --> final prototype. All functionality is done through batched processing with the digital pen and paper (i.e. all the pen strokes and data are transferred to the computer only after docking). We do not support streaming mode via bluetooth as that defeats the purpose and reason behind out project mission statement. The final implemtation of our user interface consists of a menu with 4 main tabs:

My Blog (Screenshots 18, 20, 23) - This is the default view of our application. It displays all the blog entries published by the user with the corresponding date and time stamp headings. Under each blog entry, there is a link to the comments made by other bloggers on the user's blog entry as well as a link for the blogger to edit his or her entry. The user can theoretically view the comments by clicking on the link and the interface would display them. The user can edit the entry by clicking on the link and the interface will show the editing panel with further options (Screenshots 2-5, 10-17, 19). Additional options presented to the user in the edit panel are hyperlink (ability to add a link to the world wide web in the blog entry), changing stroke width (either thinner or fatter ink width), changing ink color or background color, text selection (undo, cut, delete, background color, ink color, stroke width, insert text, insert picture), insertion (either picture or text), right click menu as well as buttons provide double functionality and extra usability, support for multiple components, component placement via drag and drop, and finally image insertion via hotspot from the paper UI the application.

My Drafts (Screenshots 6-9) - The My Drafts tab of the interface shows a listing of all the entries that were entered with the Anoto pen and were not marked for immediate publishing. The listing of entries is sorted by date headings with the full entries underneath each heading. Immediately underneath each draft entry are three buttons - "Edit", "Delete", and "Publish". The "Edit" button allows for the manipulation of the digital pen strokes of the entry much like the same functionality present in the editing panel from the My Blog tab. The "Delete" button is self explanatory as it removes the desired entry from the My Drafts tab so that users can discard unfinished drafts if they either lose interest or decide against eventually publishing them. The "Publish" button publishes the particular entry to the blog. As soon as a draft entry is chosen for publishing, it is moved from the drafts list under the My Drafts tab to the submitted entry list under the My Blog tab.

My Friends Blogs (Screenshot 24) - This is the tab where the user has the option to view the recent updates of his or her friends blogs. This is essentially a list of subscriptions that will be managed by the user. The user can select a particular friend from the left hand column to view the blog entries published only by that person. These blog entries are sorted according to time stamp. All friends's names on the left hand column are underlined to be obvious clickable links, but as an extra assurance measure we have the user's mouse cursor change from the standard arrow pointer to the hand when the mouse is hovered over a link.

My Settings (Screenshots 1, 21, 22) - The My Settings tab presents options to customize aspects of the blog entries. There are four clickable buttons under this tab and they are: "Manage Account", "Change Default Appearances", "Security settings", and "Upload Pictures". The "Change Default Appearances" option presents settings to customize the ink color, stroke width, and background color with a preview window underneath. When the user selects the option to change either background color or ink color, he or she gets a popup color palette box to choose the desired color. Then at the preview window, the user gets the choice of either saving the change or to cancel and revert back to the previous state. The "Manage Account", "Security Settings", and "Upload Pictures" options have not yet been implemented because they are not a part of our three tasks and due to obvious time constraints.

[edit]

Most difficult sections to implement and reasons for difficulty

Here are three exemplary functionalities that were extremely difficult to implement, as well as the reasons they caused us so much trouble.

Hotspot functionality: This was perhaps the hardest functionality to implement. We started out with ButterflyNet-like hotspot functionality -- the user should draw two opposing corners of a rectangle to describe a location for inserting an image on the GUI end of things. However, this did not work out too well with user testing, and users (not being familiar with ButterflyNet) were extremely confused about "opposing corners" and "marking out space for pictures". Hence we changed the ButterflyNet functionality to drawing entire boxes where the user wanted to insert an image (this was much easier to explain to users). We also inserted image placeholders and other clues into the GUI to make the user aware of the functionality. Finally, in terms of the technical implementation itself this was also probably our most complex functionality. We had to implement constraints and algorithms for detecting whether the user had drawn a hotspot into an entry and determining where exactly the user had drawn it (the boundaries of the box for inserting an image) -- credit is due to Ron for help in this area. We then had to implement the actual image insertion, complete with dialog boxes and rescaling of images to fit into the user's box. See the "changes made for Final Prototype" section above to see screen captures of the sequence of events necessary for inserting an image into a hotspot (from the GUI side).

Selection of Specific Components/Inkstrokes: The first part of this functionality concerns the manipulation of components, by which we mean text boxes and images. In our Pilot Usability testing, we received frequent complaints from users about our images and text boxes being constrained to the top of the entry, as well as about the limitation of how many of those components we allowed per entry (one each). We fixed these complaints by allowing for more than one component of each type per entry and by allowing all such components to be movable -- to do so, we had to make all components draggable and tie the mouse position to the component position when dragging, which is harder than it sounds. The second part of this functionality concerns the selection of specific inkstrokes, for cutting/pasting/changing thickness/color. Again, this was much harder than it sounds, as we had to take the mouse position into account and filter all the inkstrokes in an entry based on location to select those which were chosen for manipulation.

Batch processing: This was our first real hurdle in the project, cropping up as early as our interactive prototype. The problem we faced was that our application by its very nature did not really lend itself to streaming -- we would not be providing any real benefit to users if we required them to have a computer, with streaming software, at hand whenever they wanted to write an entry. This would largely nullify the affordances of pen and paper as compared to computers, and obliterate allowing users to write down their ideas anytime, anywhere before they were forgotten, for example. Thus, we could not depend on a large majority of the PaperToolkit functionality, and we had to essentially reinvent most of the PaperToolkit features to support batch processing (writing with the pen and then processing all the strokes after it is docked). We had to implement our own XML parser based on tutorials we found on the web, as well as our own "listeners" to take this XML data and find out if boxes had been ticked, for example.

[edit]

What was left unimplemented

What was left out and why
- Specific functionality with regards to text selection within entries (i.e. copy, paste).
  - We decided to leave out portions of text selection because it would interfere with our existing running application. Most of these functions currently do work (color changing, stroke width, cut, delete, undo, insert). However, copy and paste functions are yet to be implemented to be bug free as they currently do not function correctly. In the interest of keeping our program as error free as possible (it would be a disaster to have a partially working copy/paste combination wreck our entire application), we opt for the safer solution and leave out portions of text selection until the kinks can be worked out.
- Automated saving/publishing (cannot tell when new xml has been generated). The pen generates an xml file every time it is docked. The xml file is saved inside the data directory of the R3 toolkit (PaperToolkit\penSynch\data\) after the strokes are transferred from the pen via batched mode and must be manually copied to the data directory under the 4Corners directory.
- Minor features and areas of our interface that say "to be implemented"
  - We devoted time in completing the implementation of our representative tasks and saved these "bonus" features for last depending on time. Due to time constraints, we have completed some of these additional features but have also left some of them unimplemented.
  - Several options in the Settings tab such as "Manage Account" and "Security Settings" were not implemented.
  - Friends functionality was left out because the exact nature of adding friends will end up requiring network functionality (for requesting/accepting friends, for example).
  - All connections to the internet (actual blogging, images from internet). We did not have time to search for a suitable blogging service and look into interfacing our application with networking code.

Any wizard of oz techniques that are required to make it work
- Manual loading of xml files into application: For this prototype, this is the sequence that the user must use to input an entry into the blog:
  - Write the entry on the 4Corners Blog form.
  - Put the Anoto pen into the cradle and load the strokes in batched mode to the computer.
  - The strokes xml file should be saved in PaperToolkit\penSynch\data\ (wherever the R3 directory is located). Please copy it into the data directory under the 4Corners project folder.
- Loading of image files that you wish to insert into an entry: Any image file to be inserted into an entry must be copied into the imageData folder under the 4Corners project directory.

[edit]