a. Group number and name
Group number: 18
Group name: %eiip
b. Member names
Erica (eportnoy@), Mario (mmcgil@), Bonnie (bmeisenm@), Valya (vbarboy@)
c. Project summary
Our project is a smart bookshelf system that keeps track of which books are in it. You can see the web application portion of our project here!
d. Tasks we have chosen to support in the working prototype
Our hard task is adding an existing book collection to the system; this should consist of at least three books for testing purposes. This is the first task a user would have to complete with our system, and it consists of adding RFID tags to the books, adding them to the system using our mobile interface, and then placing the books on the shelf.
Our medium task is adding a single new book to the system; this is very similar to the previous task. It consists of using the mobile interface and an RFID tag to add a book to the bookshelf.
The easy task is finding a book on the shelf, or searching for a book that is not present. Users can choose to use our mobile app to search for a book, or they may attempt to manually search the shelf. If our system provides added value, we hope that they will opt to consult our mobile app.
e. Differences from P3 and P4
Our tasks have not changed from P3 to P4, though the interfaces the user will interact with and the workflows have changed somewhat. This is because our tasks are goal-oriented, and we believe that the goals of the system remain unchanged. Additionally, the hard task is the first task that an actual user would have to perform, so we believe that testing the proposed tasks in the order given is valuable.
f. Revised interface design
i. Changes as a result of P4 and the rationale behind these changes
The main feedback we received from our user testing was that it takes too long to add a book. In order to fix this we removed the screens that asked our users to verify the information, and we no longer require our users to photograph the cover. Instead, we now have them simply scan the barcode and we use the GoogleBooks API on our end to get the relevant information. We also noticed that many users struggle with adding a book to the system. We fixed this by adding a clear, obvious, and noticeable “Add Book” button to the main page. In user tests, users also did not use our search feature because they could see all the books on one screen. In our high-fidelity prototype, we utilized mobile design heuristics in creating a page with large text and images. A consequence of this is that fewer books are shown at a time, and the user is able to search via predictive queries, implemented using a typeahead.
From the hardware side of things, we initially wanted to use Seeed Studio RFID readers placed behind the bookshelves to statically sense the presence of multiple books, and thereby be able to inventory the contents of the shelf. Users prefered this method to a “tap-in, tap-out” approach to managing books. However, it looks like we may have to take the “tap-in, tap-out” approach since a fundamental limitation of the readers’ hardware seems to be that they can only read one tag at a time. This means that the user will have to tap each book to the scanner when replacing or removing a book.
ii. Updated storyboards
iii. Sketches
g. Overview and discussion of the new prototype
i. Implemented functionality
In this new prototype we greatly improved the book-adding paradigm. Now, instead of having to go through multiple screens and steps, a user simply takes a picture of the ISBN, puts a sticker or bookmark in the book, and places the book on the shelf. We also implemented a search function, where the users can search by author or title. We have added “Light Up” buttons to light the shelf the book is on (although the physical light is still done via wizard-of-oz techniques, as explained in more detail below). We provide no button for deleting a book, because the difference between removing a book from the shelf and deleting it from the database is unclear and we do not want our users getting confused.
We are using a computer to communicate between the Arduino and the web server, to maintain a seamless interaction from the user’s perspective. In particular, we need this setup in order to query the bookshelf state remotely from a web application. We are also using an Arduino to power, run, and communicate with the RFID readers. We are using an Arduino because we need a microcontroller of some kind to interact with the RFID scanners, and we already have an Arduino, which is relatively easy to use.
ii – iv. Left out functionality, wizard-of-oz techniques, and the rationale behind these decisions.
We decided to leave out the physical bookshelf from our high-fidelity prototype. Instead, we will continue to use a normal bookshelf and wizard-of-oz techniques to implement the physical finding of the book and the light to indicate its location. We are doing this because our user testing showed us that the aspect that we really need to work on is our application and user interface. Thus, when building our high-fidelity prototype we focused most of our efforts on that. By emphasizing these functions we hope to get better feedback from users. Our earlier feedback indicated that the workflow was most important, so we hope to test the new and improved workflow on users next week. Moreover, we had to wait on building the physical system because we had some issues with our RFID reader, and getting the wires needed to make it work. Furthermore, upon experimenting with the RFID reader we discovered that its range is smaller than we expected, and that it can only sense one RFID at a time. Because of this, we decided to change our system to have a “tap-in, tap-out” function – instead of having the bookshelf keep track of all the books that are on it, users will a tap a book to the reader when placing it on the bookshelf, and then tap it again to tell the bookshelf that they have removed the book. Getting an RFID reader that could do everything we wanted would have been expensive and not feasible, so we came up with this solution to do the best with the materials we have access to. We have a wizard-of-oz web-form which allows the user test administrator to indicate which shelf-number a user placed the book on, simulating what will later be happening via Arduino and RFID.
v. Code not written by us
For our project we used some code that was not written by our team, as well as many publicly available libraries and applications. In particular, to implement the barcode-scanning functionality of our application we used an app called pic2shop, which scans the barcode, reads the ISBN, and then sends that data to our application. We also used the Google Books API in order to get data about a given book (the title, author, and cover image) from the ISBN number. The web app itself is hosted on Heroku and built using the Python framework flask, and is based on the example application called flaskr. Twitter Bootstrap and jQuery are used for the frontend. We also used the RFID SeeedStudio Library for Arduino in order to operate the RFID scanner and read RFID tags.
h. Here are some images documenting our prototype!