Posted on

Which Technology for Your Application?

You’re having a chat with a technical partner and something like this comes up:

“We’ll set you up with React with Redux to reach out to a Python and Flask based API which was connected to gRPC microservices running on a Kubernetes cluster”.

Whether you understand what any of that means or not, it’s almost assuredly overkill for your MVP application. That kind of a setup is meant to scale to tens of thousands of daily active users; a nice goal – but a massive case of overbuilding for the vast majority of startups. The best way to develop software is through a process of progressive elaboration; start with a simple technology, get it working, add complexity as needed.

Over-engineering is a costly trap you can easily fall into. Similarly, be wary of technical vendors who are adamant about specific technologies. Shoehorning your project into something they’re comfortable with might not be a wise approach.

We believe the best software is designed around the problems you need to solve; the specifics of what platform or language it’s built on is a secondary concern. Pushing too hard on one solution to solve all problems is often a sign of a high volume firm (cranking out tons of work following the same patterns) or just a lack of deep knowledge in building software.

Posted on

Own the MVP Relationship

Focusing on building your minimum viable product (MVP), especially when your founders don’t have all the technical skills, is an exciting but challenging time for any startup.

From your dreaming, preparing businesses plans, and pitching, you have a pretty solid idea of what your MVP will be. It’s important to maintain that as a point of reference, but part of the world of software development is knowing that will change as you get more feedback about your product, its fit in the marketplace, and involve more people. Keeping that in mind you need to consider how you maintain a development environment which is flexible to your changing needs. The last thing you want is your application to be a black box of unfamiliar, inflexible, or proprietary tech. You know you need to work with outside vendors to build your app, but don’t let them dictate to you how your MVP will be built, and certainly don’t let them put you in a situation where you are locked in for later phases of the application.

A great way to make sure that flexibility is being maintained is to request that work on your MVP be completed in small deliverable pieces. Instead of building the entire app, you could focus on a user’s dashboard view first – even just putting in static data to start. This opens the possibility of testing the waters with multiple vendors. You can evaluate how you work together, their output, and real costs far better than just reading some pitches and looking at estimate numbers. It’s a great way to figure out who is really going to be a good fit as a technical partner.

Image c/o http://www.jopwell.com

 

Posted on

You’re Funded! … Now What?

So your startup just secured funding, congratulations! Whether it’s from a pitch competition, a traditional funding round, or an alternative source the next big step is getting the product ready to launch. We often work with companies at this stage, and we have a few tips about the process.

The first step is to adjust your focus; you’re no longer pitching and selling the idea but transitioning to delivering on expectations. It’s no less demanding, but requires a different mindset to succeed. You have to move from conceptual thinking to more pragmatic thinking.

The primary goal you have now is to build the smallest possible version of your product you can launch with, your minimum viable product (MVP). You (and your friends and advisors) probably have a huge list of features you want to support, but that will extend the time it takes to get to market, and if you estimate or plan poorly you may run out of funds sooner than expected. If you are out of runway you might need to ship whatever product you have, and that product may not have the key feature or timing the product needs to win the marketplace.

We strongly recommend avoiding these problems by creating a prioritized list of functionality and then building your app in such a way that value can be delivered incrementally. This is a good place to leverage your value proposition or mission statement; to really target what it is that makes you unique or you do better than anyone else.

Getting in the market (or at least in front of testers) faster allows you to get more feedback and respond to issues quickly. It’s better to find out early if you have made a bad assumption. Even working with well designed software it is much easier to change a small app than a large one; this is a big part of the philosophy behind what is called Agile software development. It’s beyond the scope of this article, but building in an Agile way aims to plan and build in response to market needs, delivering iterative versions of working software.

By focusing and building the smallest thing you can, you’ll get to market quickly and begin to really test the waters with your ideas.  

Posted on

Getting to Know Our New Neighbors

Ever since we moved into our new larger office, we’ve been exploring the neighborhood and trying to see what we can get involved with.

We’re just a block down now from the main branch of the Akron Public Library. They’re home to many interesting programs (and a great asset to the community), but the one that piqued our interest is the TechZone@Main. Offering up a wide variety of cool equipment and resources, anyone can stop in and use things like 3d printing, green screen video, audio recording studio, photo printing, laser engraving, and more.

What caught our eye was the vinyl printing. We’re working with a local company on getting some external signage for our new office, but we wanted to supplement that with some vinyl graphics for windows.

The library staff was patient and helpful as we prepared our files, and we even got to watch the printer in action, slowly building our graphics, making another pass to score the material after printing so you can easily peel off your custom shapes.

In a few minutes we had our prints; all we had to do was peel away the uncut areas and stick the vinyl to our glass.

Overall it was a great experience and we now look more official from the front door. We’re not sure if this material and approach is what we’ll use long term (and it’s hard to see in the photos), but this was quick and painless way to test it out and learn about the process.

 

Posted on

A Deep Dive into Home4Care’s Design

We recently completed the Home4Care project for Hearthstone Alzheimer Care, a company committed to meeting the evolving needs of people living with Alzheimer’s disease and dementia as well as supporting their families.

The goals were to combine the knowledge and processes Hearthstone had learned through their research with an easy to use interface for caregivers. The app offered specialized activities like games and quizzes, plus education for the caregivers and features for planning out their day.

Design Focus

The challenge of building an application whose goals included active use by people with dementia was unique and challenging for us. This was our first chance to expand upon our basic efforts at improving accessibility and making our sites and applications usable by as many people as possible.

While we’re familiar with WCAG guidelines, ARIA tags, and tools like contrast checker, we’re not experts on working with people with dementia and alzheimers. Fortunately, the team from Hearthstone is and proved to be invaluable resources in guiding our design efforts.

Critic

Initial Direction

We started out the project the way we always do; with discussions and research. We wanted to employ an aesthetic and tone that was simple and modern, but also inviting for users (many of whom may not be tech savvy). We looked to other products in the same industry space, as well as well-designed pieces from elsewhere in medical fields, caregiving, and personal planning for inspiration.

research board

We drew upon that research to present several iterations of element collages to the Hearthstone team. One of our favorite deliverables, element collages are a way to explore how an application might look without getting caught up in implementation details or worrying about content.

different ui elements

Intentional Design

Included in our element collage documents is an entire page dedicated to the rationale and accessibility concerns of different design decisions we were suggesting. While there’s certainly subjective aspects to any design, we strongly feel that the best designs are not just visually appealing and on-brand, but are formed from well-researched and thoughtful decisions, backed up with solid rationale. To that end, we think that forcing ourselves to explain ourselves early on in the process is a tough but necessary step. We also test color combinations for recommended WCAG contrast and present the findings.

Eric and Byron

Moving Forward

After some iterations through our initial designs, we quickly moved into applying these choices (colors, type, layout options) to some realistic content. We started out with a photo grid treatment for the home screen of the app – filling the screen with large touchable areas made sense and seemed like an elegant way to utilize what was essentially just 4 main options. We could update the layout based on screen orientation, and it would scale easily. When we talked through this with the Hearthstone team, we learned some valuable lessons.

menu with large clickable areas

To potential users, large touchable areas probably wouldn’t be obvious as points of interaction. Furthermore, while we took the idea of stock-style photography as a nice way to create visual interest, it was brought up that users might take the imagery too literally, or be confused by the people and activities pictured.

Armed with a better understanding, we adjusted the starting screen to use four large, obvious buttons. Those conversations helped guide our decisions throughout the project.

Into the Details

As we designed and built the application, we found ourselves looking at some details more closely than we expected. We started the project using Aleo for headlines and button choices. It’s clean and legible, but being a mild slab serif gives it a little bit of personality which we thought helped the app feel more welcoming. Even though the serifs are fairly straightforward, the feedback was that certain users might struggle to quickly read the letters in some contexts. We transitioned to Rubik, a very simple sans-serif to be as clear as possible.

We also examined the usage of ligatures. Ligatures are the connecting glyphs between certain characters in a typeface.

ligature example

They come from traditional typesetting; benefiting printing by simplifying the physical blocks that were required for frequent letter combinations. They remain in many digital forms as a nod to heritage, and give materials a traditional, stately look. We don’t usually give them second thought, but with clarity as our primary goal we chose to use font-variant-ligature in CSS to disable them, giving us a plainer, but from some studies measurably easier to read design.

Building a Design System

The actual nuts and bolts of designing different pieces for the application are where we leverage Atomic Design or similar systems. The goal is to create reusable elements that serve as building blocks for most common views and features of an application. Having such a pattern library established allowed us to build new things with consistency and speeds up development time greatly.

atomic design elements

We had a lot of fun working with the talented team at Hearthstone Alzheimer Care on this project and hope this peek behind the scenes will help you think a bit differently on your own projects.

If you’re interested in some help along the way, we’re always interested in speaking to new clients. You can contact us at info@coffeeandcode.com.

Posted on

Flight Midwest Startup Conference 2017

I recently had the opportunity to attend the second annual Flight conference in Akron. Put on by our friends at Launch League, this was a great event promoting and enriching startups regionally. Experienced founders and supporters shared their experiences on a variety of topics, and there were high quality panel discussions as well.

It was refreshing to attend Flight not as a presenter or sponsor but just a regular attendee. It was a useful change in perspective to allow myself to get immersed in the day without being preoccupied with other tasks. One thing that I thought was much improved over last year’s conference was the scope and focus of the the programming. The inaugural conference was very broad with speakers talking about everything from design to dev ops. This year it was honed in on startups and their concerns. I thought this helped with expectations and just made everything feel more organized and coherent.

Heading into the John S. Knight center for the conference

When selecting which presentations to attend I forced myself to go to things I wouldn’t normally go to. I’ve been to enough design and development talks that they really need to be a specific niche or topic to pique my interest. This turned out to be a great strategy though, as I pushed outside my comfort zone and had some great discussions.

Two of the presentations in particular I found really useful:

Mark Weisman from Navidar opened up by explaining that his company works as an technology-focused investment bank; which neither invests anything (in a traditional sense) nor functions as a bank. It was a great start to add some levity to what could be a very dry topic. He explained that their primary service is to work with companies who are entertaining buyout/acquisition offers or seeking them to try and get the best price (and the most offers) possible. There were some great stories of work that they did, and the kinds of details that most people wouldn’t even think could affect deals or valuations.

While we’re not pivoting into the finance industry, it really resonated with me how they only work with companies at a certain point in their lifecycle. It’s something we’ve done as well; we work great with teams who need to build an MVP, or need front end and design help to assist their small back-end staff. How we might better position ourselves that way and options for further defining our best clients were in my head all day after hearing this.

Ryan O’Donnell from Sellhack talked about strategies and tools for a sales process. As someone who’s always been on the creative services side of businesses, I’ve tried to stay as far away from ‘selling’ as possible. But, Ryan’s talk was fantastic and made me consider diving in headfirst to help out. His products Sellhack and Replyify help you build upon some LinkedIn strategies for finding ideal clients for your business, contacting them, and following up in an organized and efficient way. It never felt ‘sales-y’ at all, and he shared some great stories and examples of the things he actually uses day to day. We’ve always focused on passive marketing efforts, using speaking and our work relationships to find new potential clients. As we look to grow though, we’re looking at starting some more legitimate sales and content marketing efforts.

Overall, I had a great time at Flight and look forward to see what next year brings.

Posted on

Sharing What We’ve Learned

We try to give back to the web community and help others learn (as well as enriching our own skills) in a variety of ways: speaking and attending events, sponsoring things we want to see more of, and trying to participate on social media and in local community discussions. One thing we haven’t haven’t been able to do is mentoring.

We still haven’t really invested in mentoring, but we had the opportunity last week to take a baby step and worked with some new developers on some job shadowing.
Our guests came to us via Akron Women in Tech’s new Code Epic. This is a fantastic program; taking the idea of code schools and bootcamps and making it available to people who can’t afford to quit their day jobs and/or pay the steep tuition.

The developers we worked with had enough experience that we could dive right in and start walking them through our daily routines. We talked through a morning standup meeting, and then went into detail about one of the projects we’re currently working on.

All of us share an overlap of interest/skill in front-end development, so we talked through the tools/projects/frameworks we’re using, and why we made the technology choices we did.

One very interesting exercise was to look at our list of technology involved with the project. We talked through everything, and then went back and added markers by the tools that we knew prior to 2 or 3 years ago. We also made other marks to signify which technology this project is using that didn’t even exist 2 or 3 years ago. The underlying message here was that learning how to learn efficiently, the fundamentals of development, and making informed choices is easily more important than simply trying to master any specific language or environment.

After that we talked through a small feature we need to add, and discussed the pros/cons of different ways we could tackle that problem.

We wrapped up by trying to answer any questions the Code Epic grads had, and we also talked a bit about the pluses and minuses of various work arrangements: consulting or agencies, large or small, in house/product, freelance, etc.

Overall we had a great time. It was really refreshing to talk to some new developers, and learn from them as we shared a bit about what we do and what we’ve learned.

Posted on

Improve your Work by Leveling Up Your Baseline

It’s not often discussed, but it’s easy to be disheartened working as a freelancer or in a small consultancy in this business. More times than I can count, I’ve been to a conference or watched a presentation where someone describes a project they worked on with large teams, long deadlines, and tons of resources. They might discuss how they leveraged a user testing lab, or their findings after a full 508 audit (link), or how their focus on performance sped up their app and increased revenues.

You come home energized and inspired, but then it quickly fades; your projects don’t have the timelines or budgets to accommodate much of what you learned, and pitching accessibility like that to your existing clients makes it seem like an optional piece that can be opted out of. The reality is that unless it’s your niche or you’re known for specializing with it, people aren’t coming to you for a project with a heavy focus in something like accessibility.

Does that mean you abandon what you learned and mope around? Of course not! You should continue to educate current and future clients; they’re hiring you to be the experts, so don’t be afraid to share what you’ve learned and what you’re striving for.

However, there’s a way to start improving your work right now, and that’s simply to level up your baseline. The best example I can think of this is building responsively. A few years ago it was a big deal, or worth calling out (and trying to get client buy in) for building things to adapt to different screens. Now though, we don’t even think about if a project will “be responsive” or not. It’s simply the right way to build things, and the default way we approach all projects. Media queries, scalable assets, and a mobile-first approach are just the way things are done.

There’s no reason we can’t apply a similar approach across the board to our work. We can apply techniques that are new to us, or possibly just new period in bite sized ways, making them part of our default workflows.

Let’s take design and feedback for example. You might not be able to stage multiple design reviews or whole-team critique sessions, but you could probably take a couple hours midway through a project and conduct an interface audit. Once you get used to it, it shouldn’t take too long, and you’ll have a great new tool baked in to your process.

Similarly, you might have learned about improving web performance but you don’t have the time to go all-in and focus on it (like Pinterest has done. But, you can familiarize yourself with the basics of web page test, and run your project/site through it once a week to track your progress (or to highlight areas ripe for improvement). You could identify one area to try and improve, and focus on that as your work progresses.

Accessibility is another area where many of us could improve our defaults. You may not be able to make it a large priority of any given project, but you can take the time to run your text colors and sizes through WCAG tools for contrast and legibility. You can also grab a browser extension like WAVE and check the hierarchy of pages and views your working on, to keep things usable for screen readers and other assistive technologies.

Piece by piece, you begin to level up your defaults you use regardless of what you’re working on. This is a powerful technique to not only help you grow, learn, and implement current ideas and technologies, but should improve the output of any projects you’re working on. You may not have the perfect project or client to do everything you want to do, but if you keeping growing and refining your defaults, each project along the way gets better and better.

Posted on

Designing for Inclusion

A local company recently asked us to review their new application which focuses on parenting and childcare. They’re doing lots of things right and we wish them the best, but as I was going through their signup flow, something caught my eye.

The very first thing they ask as you fill in your (required) profile is “Gender” with the options “Male” or “Female”. This felt off to me, so I began researching so I could more eloquently explain myself.

There are a number of personal and life situations someone might be encountering that could make answering this a challenge, from gender identity questions to perhaps a single father not knowing if he needs to check female to be the “main/mother” on the account. Similarly, does a child with 2 parents of the same gender need different choices here?

The answer might be no to all of these, but consider that this is the first thing people have to answer about themselves. It could lead to complicated feelings and emotional responses; think about how that starts their journey with your application. Is that the right tone?

One of the best ways to avoid this is to consider if you really need to ask this information or could it be left out, or made optional later? Beyond gender, applying this test to anything you ask a user to provide is a valuable process. Why burden someone, or waste their time, or make them feel unwelcome?

Assuming you do need the information, you should offer a quick explanation in that section that explains how it’s used. Attached is an example of how Facebook explains what a user’s preferred pronoun is used for.

Pronoun usage explanation

It may seem like an edge case to you or possibly just ‘political correctness’, but this is such a simple way to address issues it’s not worth alienating even a small subset of your (potential) users.

Another idea is to offer more choices; not that anyone wants to feel like an ‘other’, but anything beyond a binary choice opens up paths to make people feel comfortable. Trying to go beyond to create a comprehensive list might even work for a particular situation, but it’s often riddled with challenges and limitations, as discussed in detail here.

When we think of accessibility, it’s often framed in terms of screen readers, valid code, and progressive enhancement techniques. I think there’s another layer we should be considering though, which is a less technical, more conceptual side. What we ask of users, and how we ask it can be just as important.

If you’re at all interested I recently read a great book that goes deeper into topics like this, Design for Real Life. I encourage you to check it out, as well as these other relevant links:

http://www.designprinciplesftw.com/collections/the-ten-principles-of-inclusive-web-design

http://blog.aarp.org/2015/08/26/how-the-americans-with-disabilities-act-benefits-all-of-us/

http://www.uxbooth.com/articles/women-on-top-inappropriate-dropdowns/

http://www.uxbooth.com/articles/inclusive-design-greater-identity-representation/

image courtesy http://www.wocintechchat.com

Posted on

The Role of Books in a Modern Tech Company

It’s cliché, but the one thing that never changes in the tech industry is that things are always changing. As of writing this I’ve been out of college about 10 years; the devices, environments, and technology I learned are so wildly out of date now that if I hadn’t continued learning, I’d have virtually nothing to offer a client.

We try to make learning and growing a priority at Coffee and Code. We love attending (and speaking) at conferences, and we’re always discussing the latest blog articles and industry news. But for a deeper understanding and more thorough levels of discourse, books are often the answer.

Anecdotally it seems like books have a love/hate place in the tech world. We like to praise authors and retweet new book announcements, but when push comes to shove many of us turn to quick answers on Stack Overflow or social media and blogs almost exclusively. Books seem to be a nice luxury for a company lounge, but not truly essential to our work anymore.

In order to explore books more fully and take our learning as a company to the next level, we started a book club. The rules are simple, choose a book as a team then break it out into reasonable chunks. Set dates to have discussion on the most recent section. The simple act of splitting a book up into sections and discussing each as a group has been refreshing. Peer pressure is an amazing force to leverage to keep yourself accountable (diet and fitness social apps lean heavily on this).

We’ve learned a few things along the way I wanted to share:

Picking titles is hard, but worth spending time on.

Choosing books that suit multiple team members, but also push your team outside their comfort zone is a tricky balancing act. Inevitably a book will probably be below someone’s skill level and likely above someone else’s (and possibly not even in their interests).

If you have a diverse group, trying to alternate between different subject matter is a solid approach. Part of the appeal though is being forced to read something you might not otherwise.

We started out with Git for Humans by David Demaree. Git is something we all use, but have very different backgrounds and proficiency with. Choosing broad topics for the first few books is a good way to get used to the format and the schedule.

Strive to accommodate format preferences.

Some people (I’m one of them) just aren’t fond of longform reading on a computer screen (or tablet/phone). This means paying the extra to get physical copies, or making sure your team has access to e-readers.

Be reasonably aggressive with your schedule.

Everyone is busy; especially in our industry. There’s always something to do, and the pressure to go ‘above and beyond’ is constant: speaking and presenting, blogging, attending Meetups, contributing to open source projects; it all adds up quickly.

It’s easy to set super long deadlines for each chapter or section, but pushing yourself a bit keeps the pressure on and helps you get through each book quicker.

Embrace honesty and have a little fun.

Nothing is set in stone here, if your team misses a session or everyone is a bit behind their reading nothing is going to fall apart. If you haven’t read the section, be honest about it. A little friendly shaming might help a team member who is behind, but remember this is all to help each other grow and learn.

Similarly, if your book discussions veer off on some tangents, that’s fine too. Learning isn’t always a linear process, and inspiration and growth can come from unexpected places.