Benjamin Bercovitz, Seng Keat Teh
Introduction[]
Our focus for Project 3 is on an aspect of the web-user interaction that has long been neglected by most websites and web applications today - how to facilitate an easier and more effective means of getting user feedback, complaints, error reporting and error fingerpointing by users/visitors of a website/web application.
Motivation: The State of Website Error Reporting & Feedback Today[]
The state of providing website feedback and error reporting on the web today is generally a very poor user experience. Across most major websites, website feedback & error reporting is often almost an afterthought.
A common typical approach is the general purpose website complaint form, providing fill-ins to specify the URL of the page with errors/problems, a drop-down list of a limited set of problem categories (often as simple and unhelpful like "General Website Comment", "Suggestion for Improvment", etc.) and a large general textbox to fill in the details of the problem. Others expect the user to write a detailed email to a given email address for website complaints. Another approach, slightly more specific than a general purpose complaint form, is to provide a small feedback form at the bottom or side of every page, where the user can leave a brief comment and a rating of the usefulness of the page to the user. Certain websites might now and then popup a dialog box, asking the user to fill-in a survey reporting their satisfaction with the site. This is often an annoying experience, as users are interrupted while engaging in their tasks on the website. And when a user later seeks out the said survey to report a problem the user had encountered, the survey is suddenly nowhere to be found.
These methods used today to elicit user feedback and complaints provide a very poor and pathetic experience to the end-user. The simple general-purpose website feedback form expects the user to describe the problems in detail, but this is often too impractical - a typical user has either simply no time or patience to write such a detailed feedback. Certain problems might also be too cumbersome to describe well in words. In such situations, users resort to taking screenshots of the problematic page, highlighting or cropping the problematic area and sending these image files with their complaint email to the website developer. Many feedback forms also provide a drop-down list of problem categories to help the user pinpoint down the problem. As mentioned, the problem categories provided are often very limited to describe the myriad possibilities of problems encountered by the user, and are more a hindrance than a help. We cannot also expect a user, when encountering an error, to interrupt his/her work to locate a website's complaint form that are often inconveniently located or hard to find. Many website complaint forms also shockingly provide only a single URL fill-in to specify only one problematic page. We certainly cannot expect the user to fill in separate complaint forms for each website problem or each problematic webpage that the user encounters.
A survey of website feedback approaches today: A generally poor user experience
Such problems remain pervasive in the industry. Apple's website, for example, shockingly uses the exact same lousy and poor general-purpose website feedback form as that of Brothers Industries, despite Apple's reputation for providing products with good user experiences. Other mentioned approaches such as a small feedback form with ratings per webpage, directly emailing the webmaster, or pop-up surveys, all suffer the same frustrating limitations as the general-purpose feedback form - the lack of an immediate way for users to visually point out and specify the problem they see to a website developer.
Can We Do Better?[]
The poor user experience we get today, when providing feedback/complaints, benefits neither the website developer nor the website user. Users get turned off from providing valid, possibly useful complaints/suggestions if it takes too much work and effort to do so. As a result, we get reduced user satisfaction and increased user frustration. Users become less satisfied when they are not able to effectively convey their concerns, and users become increasingly frustrated with a site that does not address their problems.
This situation does not help the website developer as well, who might lose out on the useful feedback that could have been given had the feedback/error reporting process been made much easier. Developers lose out on the opportunity to gain insight into what the user is thinking - what works well and what doesn't for a user when using a certain website. A website developer would also have to spend some time interpreting a purely textual, poorly-written user feedback/complaint, trying to visualize the problems, and going to the webpage itself to try to identify these problems based on a user's written description.
The general-purpose complaint form is simply too problematic, cumbersome and tedious for any end-user. We want to maximize the amount of useful feedback we can gain from our users while minimizing the time and amount of work our users need to do in order to provide useful feedback/complaints. We do not want to deter our users from providing possibly useful feedback because they get bogged down in the website error reporting process.
A Picture is Worth a Thousand Words[]
Meta-Feedback allows users to easily "fingerpoint" problems very easily on a webpage. Developers can then see the same problems visually pointed out by users.
It would be nice if there is a quick way for users to point out a problem, and a quick way for developers to visualize and see such problems as pointed out by the user. Our aim is to provide an interaction that makes website error reporting/feedback as easy and as seamless as possible. Our interaction, Meta-Feedback, will provide a website user with the ability to quickly "fingerpoint" and visually "tag" multiple problems on a webpage and annotate them with the user's comments or complaints. Website visitors can also use this interaction to highlight certain areas of the page to suggest possible improvements, feedback or even praise. The website developer will then receive a copy of the marked-up problematic webpage and open this file to view the user's visual "highlights" of the webpage's errors and the user's textual annotations.
By allowing users to visually "point-out" website problems to developers through Meta-Feedback, users can very easily make useful feedback with this visual aid. In the past, useful feedback often required detailed information, such as describing the various steps to reproduce the problem, where the problem is located or how the problem looks like. As the old saying goes, "a picture is worth a thousand words"; what was once described details can now be shown in its original visual form.
Meta-Feedback also augments and adds to currently employed techniques that measure user satisfaction with a webpage and a webpage's effectiveness. Currently techniques are mostly quantitative in nature, often measuring user clicks, clickthroughs and clicking density on different aspects of a webpage. Meta-Feedback allows developers to gain qualitative data in addition to quantitative information obtained with these techniques. Developers also gain the opportunity to iteratively refine their website based on users' likes and dislikes.
How It is Implemented[]
Client-Side[]
Our project is implemented by overlaying the whole page with a partially transparent div and then capturing mouse events played out on the div. A mouse down event signals to begin drawing a box, which is a div using absolute positioning and a border. A mouse move event after a mouse down resizes the box. Finally, a mouse up event draws the text comment window beneath the box. The comment window uses its own set of event handlers to manage changing between the edit and display states.
Turning off the meta edit mode is simple: setting the parent div's display style to none causes everything to be hidden.
The javascript implementation is compatible with Firefox and IE 7. The code to fix IE 7 represents about 10% of the total 400 line implementation.
The interesting aspects of the implementation deal with the semi-transparent background div. The div is a hack to keep the browser from highlighting images and text underneath it while the user drags the mouse around on top. For reasons we could not elucidate, it only works if it is placed by absolute positioning, which means that when the window is resized or scrolled, the div must be resized and redrawn or the user will see things underneath selected.
Server-Side[]
Our project uses XMLHttpRequest objects to create asynchronous notifications to the server. There are three different notifications in our project. When first entering edit mode, the whole page HTML (and in the future, metadata as well) is sent to the server. Then, when a box is created, the coordinates are sent to the server. Finally when a text comment is made, the text of the comment is sent back. The page has a generated random unique id, as does each box for tracking. The client and server need not establish any state.
POST /page.jsp?uid=x.xxxxxxxxxxxxxxxxx
- uid: uniquely generated once for whole page POSTDATA: the whole html content of the page and environment (OS/Browswer/Version)
GET /box.jsp?uid=x.xxxxxxxxxxxxxxxxx&box=x.xxxxxxxxxxxxxxxxx&height=xxx&width=xxx&top=xxx&left=xxx
- uid: uniquely generated once for whole page - box: uniquely generated once for each box - height: box height in pixels - width: box width in pixels - top: box top's y-coordinate - left: box left side's x-coordinate
GET /comment.jsp?box=x.xxxxxxxxxxxxxxxxx&comment=xxxxxxxxxxxxxxxx
- box: uniquely generated once for each box - comment: the user's comment content for that box
How It is Abstracted to be Reusable[]
The project we have created is very customizable and and reusable. Of course, all the usual things such as css styles and colors are customizable. It's possible to use a dashed line border instead of a solid line border, for instance. Any page or application can be readily integrated with this code: it only requires a two script tags, a div tag and a stylesheet. Future versions may easily further reduce this requirement by loading the other scripts and stylesheets dynamically from a bootstrap script. We plan to provide a namespace for it to prevent naming conflicts with pre-existing page scripts in the future. We have tested it on saved versions of several popular websites and it has worked on all of them.
- Requirements:
- Two JS files - One CSS file - Create a div container - Future release will only need a single JS bootstrap file that will dynamically load on demand
- Tunable parameters:
- Color of "selection box" - Thickness of "selection box" borders - Opacity layer covering page - Feedback mode affordance message: content, position, styling - Toggle button to switch on/off feedback/commenting mode - Change graphic, or set as text - CSS styling
- Additional possible customization: Content of comment containers
- Default: Comment/annotation/tag box - Customization: A mechanism to grade/score severity of problems - Customization: Survey question, ask user to rate how good/bad a page feature is
The Strengths and Limitations of Our Interaction[]
Strengths[]
Meta-Feedback, as a web interaction, derives its strengths from improving and transforming the website feedback/error reporting process into a much more seamless, convenient and hassle-free visual experience. Users take advantage of the visual aspect of Meta-Feedback to easily "fingerpoint" and visually highlight out webpage problems to website developers. Both website users and developers will benefit from the following strengths of Meta-Feedback:
- Ease of soliciting user feedback: Meta-Feedback makes it very easy for users to provide very useful suggestions & complaints without much effort by leveraging the visual aspect. In the past, users tend to not bother providing feedback because the process was too troublesome and cumbersome such as inconveniently located webpage feedback/complaint forms and having to write detailed comments for such feedback to be of any use.
- Knowing what a user wants: Users can inform website developers and designers which specific components of a webpage worked for them, what is missing and what more can be improved.
- Easy for user to visually “fingerpoint” problems and errors on webpage: By leveraging the visual aspect and making the feedback process a visual experience as well, users can in effect directly and visually point out a problem instead of describing it textually. This solves the situation when certain webpage problems are hard and tedious to describe well in words.
- Make website error troubleshooting a visual experience for both users and developers: The developer receives a copy of the file together with a user's visual "highlights" and annotation once a user is done commenting. Meta-Feedback effectively gives the developer the same point of view as the user. The developer sees all the problems from the user's perspective. This is a powerful and valuable aspect of Meta-Feedback.
- No sign ups currently required: Meta-Feedback, in its default configuration, doesn't require any signing in for a user to immediately comment and provide feedback through our interaction. This is valuable as sign-ins are a hassle to users and may deter them from making valuable feedback. However, Meta-Feedback can be easily customized to let a user provide an email address in order to receive a reply from developers about the user's feedback.
With Meta-Feedback, developers can also customize to instead survey user satisfaction with certain aspects/components on a webpage
- Easy to incorporate in current pages immediately: Meta-Feedback can be easily deployed in any existing webpage with very few lines of code to begin receiving user feedbacks. The required dependencies take up very little space, only about 15KB, currently uncompressed.
- Flexible/Very useful for iteratively improving a website to cater to user needs: Meta-Feedback is flexible enough such that it can be used as the following
- Feedback/complaint/error reporting (From Users to Developers): Users can provide suggestions and feedback to website developers.
- Survey user satisfaction (From Developers to Users): Developers themselves can actively seek out user feedback. They do so by configuring in Meta-Feedback mode, existing visual "highlights" that solicit user feedback/opinion regarding certain specific features of a webpage.
- Allowing greater fine-grained feedback questions about aspects of pages/interaction/website: Developers themselves can reach out to users about their opinions about different aspects of a webpage. This allows developers to gain more fine-grained user feedback.
Limitations[]
- Centering/Browser resize issue
- Solvable with shadow layouts that use a copy of the div/css layout structures for the markup application
- Possible screen size resolution issues between user and developer
- As a fallback, scrolling still works, however DOM elements may have been moved
- Setting viewer's window size is an option
- When used in combination with a shadow layout, should be fixed
- Perhaps developer should fix problems for users with low resolution?
- Pinpointing errors within dynamically-changing elements (e.g. embedded Flash movies/animations, banners)
- Adding a time signal could help to solve this
- One possible extension: A Screenshot mechanism (takes screenshots of immediate area highlight by user)
- Will require more browser support or a browser extension
- One possible extension: DOM elements selected, highlighted Firebug-style (recorded as further debug/troubleshooting data for developers)
- One complication of this approach is that we intentionally remove the previous interactivity of the underlying page
Conclusion[]
"Meta-Interaction", A New Class of Web Interaction[]
This project explores a new kind of interaction style we term a "meta interaction". This style does not actively modify the underlying website/application but instead allows for a higher layer of step-back interactions. The key aspect of this style is that it swaps the interactive style of the application while keeping the actual pixel layout. This multimodal interaction is present even in some text-based terminal applications, such as vi which has several interaction modes but one visual representation. Another example is the desktop-switching feature called Spaces in MacOS X. In screen manager mode, the user can see all the applications open on all his or her desktops and move them from one to another by dragging. This steps back and replaces the typical interaction where a mouse event is sent to the application. Another possible example of a web interaction in this style is an application that brings up a visual site map that points out and explains where to click for finding various pages/functions.
We believe that such interactions are a natural pattern of human-computer interaction and are well-suited to the web environment where pages/applications themselves are not only viewed and used, but also linked to, commented on and blogged about. The advantages of direct manipulation and in-place editing are plain in this context. It will be surprising if many popular pages do not adopt some meta interactions in the next few years, as traditional web interfaces are becoming too crowded for new, innovative features while users continue to demand spartan interfaces. Meta interactions will help alleviate this problem.