Versions Compared

Old Version 33

changes.mady.by.user Tristan Josef Naumann

Saved on

compared with

New Version 34

changes.mady.by.user Tristan Josef Naumann

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Manasi Vartak, Tristan Naumann, Chidube Ezeozue

Design

Final Design

Demo: http://youtu.be/xuxCxUd0bqM

We used a SmartBoard for our implementation instead of a web or mobile interface because user studies indicated that users would not go out of their way to get information about events through a website or mobile app. In fact, the events.mit.edu website which is a central repository for events, is hardly used by students. We envision SmartBoards (or a similar devices) being placed at the current locations of poster boards in Stata. We also chose to allow adding of posters through the smart board as opposed to having a separate web interface for simplicity and uniformity of the interface. 

...

  • Calendar View: Posters are displayed by week and users can either scroll to a week or select a data off date from the calendar.
    •   Calendar View: 
  • Similar Events View: Posters are grouped by tags event organizers assign to them (e.g. talk, social etc). Posters with multiple tags are placed in multiple categories. Clicking on a tag allows users to browse events in that category. This functionality circumvents facilitates drilled down searches without the need to need to have for an explicit search button which would require typing and which we wanted to avoid since our studies showed that typing on a vertical surface is very tediousuncomfortable and inefficient.
    •  Similar View : 
    • Browse Tag Category:  
  • Add poster view: We implemented a slide-in panel for adding posters where the user can select a poster file, event date and time, and tags. These selections require no typing , they are which is accomplished through calendar widgets and drop downs. Similarly, for entering email, we prompt the user to swipe their id ID at the RFID reader and auto-populate the email field.
    • Add View: 
  • Detailed view: When a poster is clicked on (in the calendar or similar events view), the poster is focused and the user is able to scribble on it, change scribbling color, view previous scribbles, continue a previous scribble, like/dislike a poster, and get a reminder for the event by swiping an RFID card. The . Again, we utilize an RFID reader to obtain an email for the reminder using an RFID reader, thus removing the need to type on a vertical surface and improving efficiency. Additionally, the person who posted the original poster is also able to delete the poster by swiping a card.
    • Detailed View Example 1: 
      Detailed View Example 2: 
      Send email reminder functionality: 

...

  • Before the heuristic evaluation, we put in some animation that slid in the new week when scrolling weeks but it made posters disappear briefly before showing up the poster of the new week. An evaluator thought the behavior was jarring and we removed it.
  • Some evaluators pointed out that there was no way to remove a poster added in error, for instance, so we implemented this critical authentication-based delete functionality
  • Some evaluators pointed out that since there were only two views (and hence, two buttons for switching between them), it wasn't obvious which view was selected despite our visual separation of the two. So, we added a border that made the selected view more obvious.
  • We added visual feedback to the like/dislike buttons so users could know how many likes/dislikes a poster has acquired
  • In response to an evaluator's point, we used alternating column colors in the calendar view to set the days apart but this was not visually appealing so we discarded the idea.
  • We contemplated moving the calendar to the bottom alongside the buttons for switching between view modes but the calendar would have made that panel occupy too much vertical screen estate. We also contemplated moving the view-switching buttons to the left with the calendar but the similar view does not need a calendar and such a grouping would have been inconsistent between views. Finally, we considered doing away with the calendar entirely since most users would be looking for events around the current date but we decided not to because it would make event management very inefficient for people who put up events weeks or months in advance and wish to take them down or view them. Likewise, its removal would contrast with the majority of evaluators who said they liked the calendar.
  • We removed the randomness in the ordering of the posters in the Similar Events View so that every time that view is brought up, posters remain in the same place they previously did.
  • We made the event category labels clickable to solve the problem of visibility when there are a lot of events in a category and the posters begin to overlap.
  • We changed the reminder icon from a calendar icon to an alarm clock icon because the calendar icon was confusing given other uses of a calendar (primarily in the Calendar View)
  • Evaluators thought the scribbling feature was interesting but was concerned by the lack of a way to save, erase and change the pen color of a scribble. We implemented all those features.
  • Some evaluators thought the 'x' used for closing the Add Poster dialog was not externally consistent or noticeable enough and that the dialog could not be dismissed by clicking outside it. We changed the 'x' to a much larger 'Cancel' button within the dialog but retained the strictly modal functionality for safety reasons. We wanted to prevent users from dismissing the add dialog in the middle of adding a poster and having to start all over again.
  • Hovering over a poster caused jerky behavior and we fixed it.

...

We implemented the project using a SmartBoard PN342C 4-point optical touchscreen that plugged into any computer's serial/USB ports for to register touch input and accepted VGA port /DVI for outputdisplay. To minimize dependency on the SmartBoard, we implemented the project as a website and projected it using the SmartBoard. This allows the project to be viewable from anywhere, even though we optimized the experience for the SmartBoard.

The backend for content was implemented using primarily in Python using the Django web application framework and SQLite database. We Because a browser implementation is sandboxed with respect to system hardware, we also wrote a standalone websockets server for feeding the server in Python to relay inputs from the RFID card reader to the frontend. The frontend was implemented using HTML, CSS and Javascript with a heavy reliance on the JQuery and JQuery UI libraries as well as a few other libraries. These libraries were utilized in the following ways:

  • The dialog for adding posters was implemented using JQuery UI Dialog; using Calendrical and Chosen javascript libraries for selecting dates/times and tags respectively. 
  • The Calendar View was implemented using a grid built out of HTML tables and the Similar View was implemented using absolutely positioned image elements.
  • Focusing of the posters was implemented using Colorbox javascript library and the scribbling was implemented by using SVGs with the Raphael javascript library. Additional libraries were used for displaying the color picker and old sketches.

...

Likewise, a more detailed list for the components necessary for deployment of the project can be found in the README file on github: https://github.com/tnaumann/PosterBoard/blob/master/README. Further, in order to implement a backend sufficient for the purposes of the demo, we made the following considerations:

  • When storing the sketches, we opted to store the coordinates as fractions of the height and width as sketch time as opposed to absolute coordinates to permit scaling at display time.
  • We also contemplated displaying old sketches as stacks underneath the main poster but the colorbox javascript library was not flexible enough to accommodate this. Retrospectively, our approach gives more visibility to the old posters that a stacked arrangement would have.
  • We also contemplated saving the sketches as the user sketched instead of waiting till the user was done sketching but that approach was more bug-prone and given the time limitations, we opted for the less bug-prone approach of saving when the user clicked the Save button.

One of the challenges we faced after paper prototyping was the realization that in our original concept's on-screen keyboard was simply not comfortable or efficient. While such keyboads may be efficient for mobile devices and tablet PCs, we were forced to consider alternative solutions. Ultimately, we decided to use an RFID reader to grab information from the user which would allow us to populate the email field when adding a poster as well as confirm a user's identity when sending reminders and attempting to delete a poster. This solution required not only the acquisition of a suitable RFID reader but also the implementation of a websocket server built on the RFID reader code in order to relay information from the RFID reader to the frontend which was running in a browser. the less bug-prone approach of saving when the user clicked the Save button.*** Need to talk about how we used RFID reader to remove need for typing ***

- the actual board was not functional until the week before GR5 was due. It was missing a crucial connecting cable to allow the smart board to communicate with the computer. After several tens of hours of conversations with Customer Service and three sets of incorrect cables, we finally got the board working. So resolution, fit to big screen don't happen very well.

...