Digital project reflection

I need to preface this reflection by addressing one major flaw in my idea, something that may prove a warning to potential app designers: a project like this is time consuming. Each area of disability that your app may address is as important as every other, and having a fully-featured and usable app that doesn’t leave people out is a difficult task. That said, it is absolutely important. There is no reason a population should be left out of public history’s efforts to interpret their world.

With that said, my reflection.

Starting: I’ve been working on this idea for the better part of the term, and the second hardest part of the whole process was knowing where to start. There are a lot of design methodologies out there, but as my resource listing in my final project document shows, there are few that are actually relevant or worthwhile to a project of this nature. A lot of reading for a project like this is futile, simply reading a basic document that offers no rationale or backing to the reasons for its lessons, and even more frustrating, lessons and design tips that are actually counter-productive. In one case, a design tip offered suggested that app colors tailored to the color-blind should be black and white, ignoring the wide range of forms of color-blindness.

Expanding my research, I looked at actual apps I use each day to determine if they were actually usable by the disabled. Zero had legitimate features for the visually impaired (blindness, color-blindness, visual acuity issues), several had voice commands but offered no list of commands, none had image alt text or transcripts of text (except games, all of which have subtitles). It did not provide any hope but it did offer encouragement.

Identifying the needs: the assessment of needs for the app was a very thorough process and largely focused on two areas: features that help and features that hinder. Breaking down disability into primary areas, feature assessment was an A/B process: for low sight users, for example, what helps is a voiceover feature and what doesn’t is un-tagged, captionless photos. The needs, once broken out, made the itemization of features less difficult.

Identifying the who: after taking a scientific approach to the app needs, it was important to look into the human side. Looking at what disabled users want and need, determining the form and nature of focus groups, and determining what level of input they would have, was a careful process. On one hand, responsive design requires user input, but on the other hand, this was input prior to actual design and programming. Visioning may be a good word for this part of the process, but a more precise term would be laying the groundwork.

Creating metrics for success: before design, it was also important to be aware of what a successful app would do. Knowing the basic features, finding a basis for what a successful app would do was easy: it would offer as many people as possible access to interpretative histories of the target area. That leads to another metric for success: how does the app respond to the needs of diverse disabled populations? A well-programmed app would need almost no after-the-fact input to improve usability, or, at the most, additions of disability areas that do not fundamentally alter the design of the app.

Tools created for implementation: As the final document details, having a process is important, but having checkboxes is even more so. It is one thing to include addressing the disabled population in your design process, but entirely another to ensure they are included as an actual design goal. Furthermore, having a sample flowchart that shows the practical ease of sketching out the end product is a great starting point for designers, even if the flowchart only shows opening features of the app.

Final reflection: throughout this process I have become increasingly aware of my own limitations and what would help or hinder me in using an app. Early on, I had determined that triggering the app’s tour features when in proximity to a tour site was important, but as I myself reflected on my difficulties reaching locations in major tourist areas, it became more important to have clear and detailed lists of these sites. Early on, it did not occur to me that having a voice command feature needed to be featured as equal to the other features, but instead was a bonus: I can’t speak, however, so why would a voice command be an extra added bonus? Finally, speaking and scrolling speed of assisted touring features like voiceover and transcripting was something I did not consider.

As I’ve stated, with 33% of the LGBTQ population having some form of disability, it is important that community-related apps are accessible. And not just accessible, but assistive and adaptable. Utilizing these three principles, Accessibility, Assistability, and Adaptability, the underlying process of creating the app became one that was mission-oriented rather than goal-oriented. It isn’t enough that an app be working toward a goal of being open to all, it should also be working toward the mission of making disability a common and regular concern of the programming community. Disabled people should have access to history, and apps in general, and it is vital that the process be done in a considerate and meaningful way.


Howdy all, I’ve been working on mockups and a flowchart for access. The mockups suck, but I made sure the flowchart was functional and at least in a strong beta form.

Attached are the files:



Data visualization and scholarly publishing: Scalar

Scalar is a University of Southern California and Alliance for Networking Visual Culture project that aims to create a platform for the creation and management of scholarly documents in a visually appealing and modular way. The main draw to Scalar is its use of a  multimedia, multiplatform approach to data visualization.

A good example of born-digital, Scalar provides scholars with the tools to create unique and personalized presentations of their work in a format that is from online and for online. 

The basics

As a scholarly platform, Scala is naturally intended for members of institutions like universities and museums. In order to prevent overload of their system or general abuse by people who are simply interested but not for scholarly purposes, a registration code is necessary. As a result, it wasn’t possible to test the platform as it doesn’t seem to be monitored as much as one would hope. Still, someday my registration code will come.

That said, as a born digital platform, Scalar does have online tutorials and overviews of their platform. 

A registered user that has received their registration code in a timely manner would be able to perform some fairly robust digital data presentation feats with Scalar thanks to its scholar-oriented programming. The most important of these are the importation of products from YouTube/Vimeo/etc. and the ability to utilize multiple types of formats like Adobe Illustrator, PDFs, and so forth. In general, the formats and functional programs that scholars use frequently. 

Scalar is also fairly compatible with a wide range of web standards that utilize HTML5 when needed and presenting information in a way that can be coded in a portable, intelligible way that can be carried over to other platforms that utilize these standards. This carries over to the front-end and API, which both forego proprietary, walled-off code, for an extremely functional and forgiving interface that allows both live interface with other platforms, but also code that can be understood by users of other platforms. 

The API, advertised as an Open API, provides the user with a means of presenting their works on their own website and for sharing it in a way that can be modified and posted on other platforms and websites. This is unique in the world of scholarly platforms as most are walled-off and opaque when it comes to code and functional interface with other platforms. You know who I’m talking about. 

As far as crafting your work goes, Scalar has clearly made an effort to open up the system to the kind of visualization and functionality that is oriented toward the modern visually appealing, born-digital work that has been increasingly common. Prior to Scalar, hand-coding or using a proprietary, closed source platform was the norm, or scholars were presented with a low-tech and low-functionality platform. In either case, scholars were stuck.

Here, in Scalar, the user is given the ability to index reams of data and feed them into visualizations. Data can be tabbed to a specific page or can be global. A page can draw from both its native data and the global data, allowing for uncomplicated management of contextually sensitive data that requires an approach from its own base in order to keep it well-organized. The visualization from there is simple plug-and-play, using multiple types of visualizations like charts, webs, and tables.

A scholar will be able to create a multiple-page, visually robust document, but it can then be presented for one of the most important aspects of scholarly writing: review.

Scalar is different from a lot of platforms in that it gives readers and reviewers the ability to comment and offer feedback in numerous ways and on numerous pages with little fuss. The feedback capability is a core function and can be disabled for release of the final, reviewed and edited product. 


As I only had access to online documentation, it is hard to make an honest assessment of the functionality within the system. On the other hand, it provides a fine selection of presentations that use Scalar, including Seth Rogoff’s The Nature of Dreams (

As a platform for scholars, Scalar gives a lot of deference to the needs of scholars, and as such it models a good deal of important best practices for this kind of platform and interface. The most important of these, data and narrative organization, is a core consideration. An open API and portability are vital, and scholars should endeavor to make sure they present their information in a way that can be moved and molded to numerous platforms: most scholars are not limiting themselves to a single platform, so platforms like Scalar should play fair with other platforms (even if those platforms don’t play well with others). Scholars should look for—and demand—open APIs and intelligible code that can interface with other platforms.

As far as data and visualization, Scalar gives the scholar an ability to massively sculpt data landscapes that are otherwise hard to condense. Here, Scalar models another best practice, and that’s giving the scholar multiple levels of visualization and portability within the platform. It also helps break the scholar free of the classic digital visualization standard of simplicity under siloed data presentation. There is no need here to force all data into one bucket, there are multiple approaches to the data management and multiple data buckets are available, along with a global one.

Finally, Scalar opens up the scholarly world to a truth that’s necessary to acknowledge: publishing and data presentation are increasingly going to be “born digital” and it is vital to learn how to create such functional documents. Instead of relying on just classic presentation or proprietary platforms, Scalar gives scholars the ability to functionally interface with the classic and the digital, all starting from a digital base.

Criticisms of the platform are few for me, chief among them being the difficulty in access. For a platform that endeavors to not wall off the data and presentation, access should be much easier. Again, waiting for that registration code. Another criticism is the subtle suggestion that classic methods of publishing will be supplanted by this type of platform. Both, digital and classic articles, will be the norm for at least another generation. Within years, most digital standards will be obsolete. It is better, then, to work from a belief that you are modeling best practices while offering the best available platform in the current digital era. 

Otherwise, Scalar is a solid 7/10 for me.

Digital History Project: Accessible History

My project is an app proposal/framework for an LGBTQ tour app that incorporates accessibility features to model that idea that accessibility is important in interpretive media that deals with the LGBTQ community.

NB: Presented below is my practically-final framework document but, as you might notice, no prototype. Why would a nearly-finished project come without the prototype? Well, long story short: the technology. But also the work in finalizing a working document takes quite a bit of time! So you will all see the prototype or sketches soon and for now my foundational document.

Proposal: a methodology and best practices for creating an accessible LGBTQ history app

Need and purpose: as a high percentage of LGBTQ people are disabled and the disabled are often otherwise unserved by mobile apps, making a habit of having universal, accessible design in these sorts of apps is imperative.

Discussion: Around a third of LGBTQ Americans are disabled, a percentage larger than the general non-LGBTQ population. In this statistic, a need emerges, and in the context of apps in the area of history and interpretation this need is acute. As a largely detail-heavy, often visual method, historic interpretation is an area in which the disabled population is likely to be left out.

Considerations made when creating a mobile app generally focus on making it as accessible to the general population as possible with as little extraneous detail as can be managed. Unfortunately, many of these extraneous details happen to be related to accessibility. Knowing that there are so many LGBTQ users that are disabled, however, it’s important to be aware of what is left out and what needs to be near-mandatory in any interpretive app. Unpacking the issue, the areas in which accessibility in an app, especially interpretive app, can be summed up in the following areas (not a comprehensive list):

Visual: limited vision, blindness, colorblindness, visual processing issues.

Auditory: limited hearing, deafness which can be determined by a Hearing Test, auditory processing issues.

Tactile: discomfort with vibration.

Cognitive: sensory sensitivity.

Mobility: inability to access interpretive sites, difficulty accessing sites, limited range of motion in hands.

The wide range of disabilities that can impact an interpretive mobile app may seem daunting at first and deciding upon your audience may make it tempting to start with a process that aims to make the app accessible after the fact. For example, the interface may be presented in a way that is engineered to be streamlined but artistically appealing, however, in these considerations the needs of the visually disabled are left at the wayside. Take a look at your favorite app right now. Does the app present on first glance an option for the blind like screen reading or voice commands? Is the color scheme usable for the colorblind? Are there unnecessary scrolling parts or transitions that might be difficult to process for some?

A framework for accessible app UI: in order to explore the process of creating an accessible interpretive app I began to consider the creation of an interpretive tour app focused on LGBTQ history in the Washington, DC area. The process was broken down into the following parts:

  1. Establishing the app idea and general functionality and initial layout
  2. Planning functionality and layout to incorporate base accessibility functions
  3. Sketching out both a layout and a flowchart demarcating the accessibility areas
  4. Focus testing the proposal with those with disabilities
  5. Applying focus test suggestions, then testing them with a second focus group
  6. Beginning work on the overall app

As one can see the first two steps are essentially the same but with one important aspect attached, the need to go back to the drawing board, as it were, included promptly after the initial planning. This is not an attempt to increase workload, but rather it is a method of acknowledging existing oversights in the UI process: generally, even the most attentive and aware will forget functionality that serves particular populations.

For the purposes of the proposed interpretive app, the core considerations align with a brief checklist:

_ Is opening the app easy for everyone (no unnecessary buttons, sounds, text, scrolling)

_ Does the app have methods for access beyond button push (voice commands, button input from external devices)

_ Is the app visually appealing without being inaccessible (color scheme fits the colorblind, fonts are bold and clearly identified)

_ Is the functionality capable of presenting information accessibly (various options for information presentation)

_ Is it fun

The process begins by filtering every decision through basic rules of design for accessibility. This effort is important to begin at the visioning stage of app development and can be summed up in a basic (but not comprehensive) way as such:

  • The app should be navigable by voice command, screen tap, or external input (if possible)
  • Buttons and other visual elements should not blend together, this includes in the case of being indistinct to those with colorblindness
  • Any text should have a voice component and any voice component should have a transcript
  • Alerts and notifications in-app should be gently tactile and on-screen in a noticeable way
  • Customization of sensible functions like vibration and voice narration should be logical and simple
  • Users should not be forced to use functions that are potentially not usable for them (for example, voice command functionality)

The next part of the process, implementation, is followed by another set of steps and consideration for use in the focus group testing:

  • Is the focus group representative of the populations impacted by design elements?
  • Is the app tested both live and for basic functionality?
  • Are there scripts for specific live and functionality tests that can determine if all focus populations can access a specific function?
  • How are the focus group suggestions to be assessed?

Finally, implementation of the suggestions from the focus groups should follow the following considerations:

  • What is missing?
  • Where in live testing is there the most difficulty?
  • What functions are difficult or an obstruction?
  • What functions are unnecessary for the app?

From there, app design should proceed.


Material Design, Accessibility

UX Collective, How to make an app accessible?

Apple, Human Interface Guidelines – Accessibility

Android Developers, Accessibility Overview