Over the past year, I’ve been working as the solo designer embedded in a team of mostly developers and one project manager designing web experiences and publishing software for one of our clients, Rivals.com. We follow an agile methodology and work hard to effectively and efficiently integrate design. This blog post breaks down the major phases of our process and illustrates, at a high level, the role of design throughout.
When developing websites it is important to consider your audience and how they interact with your application. This can be even more significant for a person with disabilities. Even the most stunning visual presentation can lose its value when the content cannot be interpreted by an individual due to, for example, a learning disability or difficulty seeing. Therefore, it is important, when doing any development or design, we do not dismiss the 1 in 5 people that would benefit on an accessible web.
Upon hearing the term cross-cultural UX design most people might be unsure what it means and find it a mouthful to say. As the name suggests, cross-cultural UX design is when designers create a product that can be an enjoyable user experience for all people of all countries and cultures throughout the world. It makes sense that this is a relatively unknown and new term as it has only been used in recent years as our world experiences rapid globalization. Below I put together 6 major points to take into consideration when designing cross-cultural user experiences.
A common way to describe requirements on Agile projects is through the use of user story mapping, and, as a result, user stories. This post will not cover this process, but rather the process of taking an existing set of user stories and leveraging them within our development workflow to ensure that an application is built as accurately and efficiently as possible. To this effect, we will set up tools (Rails, RSpec, Capybara, FactoryGirl, and Guard, to be precise) for implementing our app using behavior-driven development. Structuring our app in this way gives us much better odds of producing robust, low-defect code that delivers on the requirements we set out to build.
I use Chrome extensions all the time and decided it was time to figure out how to make my own. I found it to be incredibly easy and I’d like to share with you some of the basics, as well as an example of an extension I made. Let’s get started!
To get a better handle on Erlang’s behavior, I decided to install a popular set of tools for debugging and performance profiling: EPER. I think it stands for “Erlang PERformance tools”, but it could also mean “Everything Proves Erlang Rules” or “Egrets Prefer to Eat Robots” or really anything for that matter. One thing is for certain, however: getting these tools built and running on Mac OS X was fraught with danger and build errors.