GR6-User Testing

Design:

For Screenshots and Description/Discussions See → GR5-Implementation

Implementation:

The biggest thing that bothered us while doing the implementation was the fact that we weren't able to implement back-end on the level our application would require in the real world. We looked around, we read a lot, but it turns out that it's pretty hard, if possible, to take screen shots of the pages in real time. This made us think about using IFrame instead of screen shots. This would also enable user to interact with the page directly without a need to open it in a new tab. We haven't done this since a lot of work with pictures has already been done, and we realized it was ok for the scope of this class not to have updated screenshots of the desired pages, but it is something we might consider in the future if we decide to work on this project some more.

One of the big challenges of our application was to make it different from the existing one on the market. This involved an idea of visualizing our bookmarks better than it has been done in the past. We had an idea of representing them in a similar way Safari represents its history pages. The pages are easy to see, and the animation and visual effects are very pleasurable and easy to use. However, we couldn't actually find this code anywhere so we can reuse it in our app. We decided to make it from scratch. We used webkit transition property to make it look like animation=move slowly, disappear gradually, etc. This caused our app not to work properly in firefox. It just didn't want to do animation even though we used transform kit specific to mozzila. When the arrow keys were pressed, bookmarks changed their position and size, making them look like they are rotating left and right with the arrows keys presses. When they go out of scope of the screen, they become invisible.

Since this animation was hardcoded to fit perfectly inside of a specific div size, it was hard for us to implement horizontal scaling of our main div with the window size. So we made a decision to keep the width of our website constant,and just center it as the width of the window changes. The pro of this decision was that it was easier to implement and that it would fit to any size of the window (at least the ones that are currently popular window sizes among the users). The cons were that on the HD screens with huge resolution, our main part of the page looked small. Even though this is how a lot of webpages are implemented nowadays, bookmark visibility is very important for our app. We went with this decision however, hoping that users on hd screens will be able to apply cmd + if they decide that they want a bigger app :).

We chose to implement warning messages and error messages through “soft” pop-ups where the function for opening the popups was very general. Because most of the warnings and messages could be classified into several categories where inside the category only a message is changed, we made the function for opening the pop-up messages very modular and general such that it can be used across the platform, for different purpose, only by changing the argument.

Because we implemented a function that draws the bookmarks from the array of bookmark objects, we were able to achieve high modularity in changing the content of the bookmark view. Bookmark view changes every time someone presses a key in the search box, clicks on a folder, or clicks on one of the shaded bookmarks, or presses the arrow keys in order to scroll. In all of these cases, our approach was to detect the bookmarks that should currently be drawn and then use the function to draw them.

The implementation of folders was done through the dictionary where keys were folder name and values were arrays of bookmarks corresponding to a particular folder name. This implementation limited us in a way that we needed to enforce that folders have different names; however, we believed that this is a reasonable enforcement and one that we could easily change if needed by implementing unique folder ids.

The implementation of scrolling through clicks was done by simply attaching a listener to every image that is added as a bookmark and then detecting its position in relation to the current front bookmark and then rotating all the images in the appropriate direction appropriate number of steps.

The implementation of the drag-and-drop feature for copying bookmarks between folders was particularly challenging. The trouble was that browser associates default actions with the mousedown and mouseup events. We spent some time understanding how to prevent browser default events, but at the same time have the events propagated to our listeners.

Evaluation:

Briefing

"You heard about a new website for managing bookmarks from your friends and you decide to check it out. You land on a page that you are seeing right now. We will give you a few tasks that aim to test this user interface. Please think aloud and feel free to explore the interface."

(We believe that our landing page does a very good job of explaining to the users what MyWeb is all about so we kept our briefing short and simple.)

Tasks

The tasks we gave to users were divided into three main categories as specified in our previous reports:

1. Creating and Managing the Account on MyWeb
2. Interacting with my MyWeb
3. Sharing

Each of these three main categories is divided into sub-tasks that we gave to users. 

“Creating and Managing the Account on MyWeb” task contained:

• Sign up for MyWeb
• Import bookmarks from Firefox
• Import bookmarks additionally from Chrome (once user is already logged in)

“Interacting with my MyWeb” task contained:

• Tell us what you think you are seeing now (given immediately after sign up/log in)
• Create a new folder and name it “Classes”
• Add a bookmark for 6.813 stellar page to folder Classes.
• Create a new folder, name it “MIT” and move your bookmark for 6.813 from folder Classes to folder MIT.   
  • Would you expect the bookmark to be present in both folders or only in MIT?
• Remove folder Classes
• Find all the bookmarks that contain word “stellar” in their name** What do you expect that search does? 
  • Where does it search?
• View all the bookmarks you have

“Sharing” task contained:

• Add Jovana to your contacts.
• Share 6.813 stellar page bookmark with your contact Jovana. 
  • What do you need to know for this task?
  • How would you obtain it?
• Delete Jovana from your contacts. 

Observations

User #1 and User #2 belong to our tech-savy group. They are both MIT students with substantial computer experience. User #1 is advanced bookmark user, having hundreds of bookmarks in different browsers. He is also what we qualify as a many-devicer, since he has PC, iMac, iPhone and MacBook Pro, but also a couple of computers in NY and France, which would make distance access to bookmarks for him very beneficial.

User #2 was also an advanced bookmark user, having a lot of bookmarks in a lot of folders.

Inexperienced user was our third test person. Our vision when we started this project was that it should also be useful to people who are non tech savvy – people who essentially use 2 to 3 websites repeatedly. Because of this we thought that it would be appropriate to test that kind of person. This was one of our member friend’s mother, who uses a computer primarily for email, but “would like to learn how to use more websites”.

We explained this user what the bookmarks are because she was not familiar with the concept. Then we walked here through the standard set of tasks

Usability problems and solutions

We discovered some usability problems with our interface. Some were there because we didn't have time to implement every possible detail we have planned on time, some were there because we forgot to implement them, but some brought to table new ideas and solutions, different than user testing input on our paper prototype. Here we try to summarize usability problems we have discovered through our user testing, TA suggestions, and some that we have noticed ourselves.

Reflection:

We wish we had some more time to implement some of the features that we got the ideas for after our paper prototype. For instance, it would be very useful to have Google search inside the app, so that people do not have to leave the app if they don’t know the exact url (which happens very often).

Looking back at this semester, paper prototyping session was very useful because it pointed out a few major problems with our design which we corrected in time for the computer prototype version. We were also told to design paper prototype like only the sky is the limit in the UI world, and don't think a lot about implementation. However, we feel that designing paper prototype without thinking about implementation in advance might make it harder to implement things later on. If you design something for paper prototype that has a great UI idea behind it, but is very hard or even impossible by current standards to implement, you have to options: 1. try to implement the idea, stick to it, spend a lot of time and might or might not succeed or 2. drop the idea and try something else, but then you won't have the benefits of paper prototype user testing of that new idea, unless you conduct it again. One of the examples, is our scrollbar. From the UI point of view, it sounded awesome, it would have been useful because users could a) drag the bookmarks around and b) see the amount of bookmarks left to be seen and already skipped based on the size of the scrollbar. We tested our peper prototype with a scrollbar, not the arrow buttons. However, with the design we had, it turned out to be very hard to implement a scroll as we wanted it in the limited time, so we wasted a lot of effort and time trying to do it and in the end went for the arrows that we didn't test or discussed with our users.

Next in line was computer prototype evaluation conducted by our classmates. This wasn't particularly useful and here is why: at that stage, our interface as well as interfaces of others(we know this because we also tested them) had so many unimplemented parts, bugs and unfinished design, that all the evaluations focused mainly on that. Basically a lot of the comments were commenting on the stuff we were certainly planning to do, but didn't have time to implement just yet. We're not saying all of the evaluations were useless, not at all, but maybe it would've been much better if the evaluation was done a little later, maybe only a week later in time when we could've finished majority of things and get proper feedback from our classmates. We also felt that it was bad that we couldn't discuss our problems with our evaluators afterwards, which would help us get more feedback and discuss different solutions.Maybe all of this could be considered as suggestions for years to come in 6.813?

Final user testing was quite useful in pointing out problems that we should focus on in the future if we continue to pursue this project. It was also quite interesting because it diagnosed some issues in our UI that were impossible to spot in our paper prototype testing, for example drag and drop, and things that can only be faithfully represented inside of a computer. :)

Finally, when it came to implementation, even though we weren't asked to think about browser compatibility and scalability of our code in the beginning, we feel that it would be better to start off your code by thinking about thing like that in advance. For example, doing everything with fixed and absolute positioning was easy, but was later pain in the neck to convert the whole code to use relative positioning. Some things were even impossible to properly implement with relative positioning. Also, once you make your code compatible with one browser, it takes ages to make it work on another one too. IT would be much easier to figure it out as you go along, then leave it for later. Conclusion: thinking about window sizes, browser compatibility and other scalability issues should be done right as you begin your coding process, it's more complicated then, but sure makes things easier later on.