Week 2 Goals

1. Create maximal character set, numerals, and punctuation for low vision font.
2. Create .otf for low vision font.

Part 1: User testing contact

I have finished adapting uppercase letters, numbers, and punctuation for my low vision font. These finished characters are as follows:

As with the previous letterforms, the most significant alterations are related to expanding letter width, specifically of letters with counters. Some other alterations included adding branches to I and J to further differentiate these letterforms.

Part 1: Creating .otf

Using these characters and the characters I created last week, I created an admittedly minimal .otf file using font forge. A few characters still need more alterations, which I will take care of next week.

This file is still incomplete, as I will need to create some form of a kerning table. My dyslexic font also needs a kerning table. I will also take care of this next week.

Reflection

This week was not my most productive, but I still made substantial progress towards my goals. I intend to pick up the slack this next week and get back on schedule. Time management has been a real challenge this past week, and the weight of my 19 credit schedule is becoming clear. Managing my schedule will be increasingly important in the coming weeks.

Elevator Pitch

I will create a variable typeface whose aspects can be adjusted by the user to optimize readability. Adjustable aspects will include low vision and dyslexic accommodations.

Project Milestones

30%

1. Finalize static dyslexic font.
2. Connect with Colorado Center for the Blind about user testing, and test dyslexic static typeface.
3. Create low vision font.
4. Get familiar with the variable type creation process through Glyphs.

50%

1. Create multi axis adjustable variable version.
2. Conduct another round of user testing and revisions for static fonts.
3. Get familiar with the variable type creation process through Glyphs.

90%

1. Conduct 2 rounds of user testing for variable font.
2. Finalize variable fonts after conducting last round of user testing and revision.
3. Create demo website with graphic UI for variable font.
4. Begin SDK development.

100%

1. Conduct final round of user testing for variable font and finalize.
2. Finish SDK and publish.

Using the app I completed last week, I conducted user interviews with two of my roommates. Primarily I was pursuing information relating to the core friend-centric nature of my app, which differs substantially from my peers’ apps, which focused more on individual books. Additionally I wanted to gather information on a minor innovation of my own, the title bars which double as search fields.

User 1:

My first user immediately wanted to search for a book to see whether any of their friends had it in their collections, and were confused when this wasn’t possible. After a brief explanation, they looked through friend’s collections to see books their friends liked. This was interesting to them, but didn’t fulfill their initial desire to find a specific book. In their words, “book choice is very personal”, and even though they might be interested in someone else’s book choice, it wouldn’t necessarily influence their own.

User 2:

My second user was most interested in using the app to manage their own book collection. Though they appreciated the usefulness of the API in streamlining the onboarding process, they recommended that adding books by scanning barcodes would probably be the easiest solution. When searching for books, they also desired the ability to locate a specific book among friends’ collections. They were satisfied with the ability to browse through friend’s collections. Overall they liked the app, and found the layout comfortable and easily navigable.

Revisions:

Based on the feedback of my peers I decided to add functionality to allow searches for a specific book. When adding the feature I wished to avoid compromising my initial friend-focused experience, since I believe most of the value of the app lies in it’s social applications. To accomplish this I simply added another button under the “My Friends” section, weighted less heavily than the friends scroll menu but still accented with a black button. This button links to a search functionality similar to the one I used to onboard books by title.

This is my version of an app for personal library management. It is designed to allow a user to manage their own personal library, including managing books available for lend, as well as view friend’s libraries and request to borrow books from them.

Adding a book to the library is accomplished primarily using an API, although there is a manual entry possible for unlisted books. The API searches based on titles, and from there the user selects the correct book and adds it to their library.

Libraries are searchable by title, and can be filtered using genre keywords.

To best visualize optimum run times, I chose to condense all weather data down into a simple color gradient. Green means good for running, yellow means mediocre, and red means poor for running. I chose not to clutter the interface with excess info like temperature or precipitation chances – this could be easily added by tapping any of the bars, but seems unnecessary for the main screen.

Edward Tufte’s article dealt primarily with refining and critiquing existing data visualizations. His primary point in this chapter had to do with removing excess visual information. Tufte separates all visual content into “data-ink” and all other content. He advocates for maximizing data-ink and minimizing all other content, within reason. This approach champions the data above all else, and leaves little room for aesthetics. This approach is likely most appropriate for scientific publications, where good aesthetics are not necessary to engage the reader with the information. Although championing data above all else is likely good practice when designing any data visualization, reader engagement through aesthetics must also be considered to maximize usability.

1. First I put my iPhone in black and white mode and ran through a few of the apps that I use everyday. In these cases, my familiarity with the layouts made it so that my interactions were minimally different – I was not relying on colors for clues about layout and prefered HCI. However, once I switched to a new app with which I have little familiarity (in this case Instagram), the roles that colors play became much more distinct. In particular, I found myself searching for the apple “action blue” color, but finding only gray. Black and white mode also drastically affects contrast. Since red/blue or “horizontal” isn’t possible with black and white, tones that would generally have no contrast issues turned to shades of gray and melded with adjacent objects. I can only imagine the problems this might cause for low vision users. Eliminating colors did seem to make all the apps less interesting overall though, and would likely result in less screen time for my if I had this setting turned on all the time.
2. Next I tried switch control, using my screen as a single button. I struggled at first, since the system is so foreign, but quickly figured most things out. It is an amazing feat of design that this system works so fell with so few inputs. In particular, the scrolling touch features were very useful, and could be amazingly precise with only one input. Pretty cool! I navigated through most the same apps without too much trouble, although typing and passwords were a huge time sink. I would imagine that after using this system for a while it could become second nature.

The most insidious misconception about accessibility is that designing with accessibility in mind somehow makes your project worse for the larger population. In fact, the opposite is true; designing for extremes also improves design for those in the middle. For example, wheelchair access was discussed in this article. The first accomodation for wheelchair access was a ramp to a side door. The second adaptation was a integrated ramp and staircase. The first example was out of the way, looked like an afterthought, and was generally ugly. The second adaptation was centrally located, could be used by anyone, and was generally attractive. This stair/ramp not only facilitated wheelchair access but a range of other circumstances, such as people pushing strollers, dollys, or carrying heavy loads. In this case, designing for those who need improved the experience for all.

Seeing a comprehensive list of disabilities puts into perspective the monumental task of designing for all of them. It is unsurprising the web accessibility isn’t all that good, since this task is often put on a single developer, and isn’t even the bulk of their workload. This tendency stems from a fundamental misunderstanding of accessibility design and it’s importance. Designing for accessibility is important not just from a business – equitable access for all is a moral responsibility for most designers.

Grids: Altogether, I am sceptical of the mutli-column layout for mobile development. Taking into account Zhulidin’s rules for layout, there seems to be very limited space for any more columns than 2. Afterall, their grid guideline calls for 12 organizational columns, which seems like a lot but ultimately provides little flexibility for a mutli-column layout. For example, for a two column layout, each column is secured 6 grid areas. This in itself is limiting, especially when the iPhone 8 has a width of only 750 pixels. This dimension serves as a lower bound for responsive design.

Color: To be frank, none of this color article struck me as particularly insightful. It seems fairly self evident from a design perspective that colors are largely dependent on the context in which which they are presented. The most remarkable proposition in this article was that sans-serif fonts are less readable because of their design history. This idea is based on outdated research which is much more controversial now.