I’m super exited about CSS grid, because finally there will be a way to layout pages and achieve more interesting and dynamic results, without a ton of code! So since I fell in love with Atom IDE recently (I know, I’m late to the party, but really I like it 😺), then it’s no surprise that I will be using it for this example on using CSS grid for layout.
The heart of creating a LSG is the ability to put your documentation right where it belongs: in the source code. Chances are that you are already documenting your code, which is a great opportunity to take it to the next level by using a style guide generator that can turn those comments into an organized site, letting others (and yourself from the future) know why and what has been done in the code.
While the bulk of your LSG documentation will come from special comments that you add to the source code, you can also create standalone pages where you can host other types of content that are not specific to the code (think of design principles, accessibility guidelines, or pull request guidelines). This gives you the advantage of centralizing your documentation in one place: your application living style guide.
Using a living style guide (LSG) to drive development is a practice that is gaining a lot of popularity because its many advantages, including code efficiency and UI consistency. But, how can you create one? What should you include? And where do you even start? In this 3 part tutorial I will delve into the nitty-gritty details of creating a living style using DocumentCSS.
Imagine this: you’re a designer who has been tagged on a pull request as a reviewer. It’s up to you to look at the changes made and decide if you are going to approve them and let them frolic with the rest of the app code.
User testing is a great way to validate assumptions and gain new insights about how people interact with our websites and apps. When it comes to eCommerce (and in particular mobile commerce or “mCommerce”) it’s critical to understand how people find and purchase products online. This was evident on one project where we were tasked with testing the mobile website design for retail membership giant, Sam’s. As it turns out, there are many common navigation patterns that aren’t nearly as effective as people might think.
Think of the app on your phone that you love using: the one that just makes sense when you use it, the one that feels like it was built with you in mind. This is good UX or User Experience. Good UX makes an application sticky; it invites new users and retains active users. UX is the process of designing an application (or product) that is intuitive for people to use by considering how they will use it. Intuitive interactions are important for every project simply because people like things that are ‘easy to use’. However, creating a product that is easy to use takes lot of time, expertise, and iterations.
There is nothing more rewarding than watching people use your app and seeing how they interact with it. User testing is a lot like making dinner for someone; you choose a recipe, ingredients, and invest time making a meal you hope your guests will like. Then you sit down with them and talk about what is good about the meal, what could be improved, and if you’d make it again. At Bitovi, we put a lot of value on testing our designs (and our assumptions!) to be sure we’re building the right thing for our clients and our clients' customers.
While re-designing the CanJS website, I ran into a few issues coding the new layout. I needed a way to create a fixed header and a fixed flexible sidebar that would adjust its width based on its content. This meant that the main content container also needed to flex to accommodate more or less sidebar content. This post will show you how I created this layout hack using Flexbox and I will explain how to create your own html template that contains the following:
Most UX processes value low-fidelity design early in a project’s life: simple, hand-drawn sketches, basic wireframes, and even boxy prototypes. It isn’t until later in the process, as the details get filled in, that higher fidelity designs get introduced. It makes sense: lo-fi designs are quick and easy which makes for faster turn-around in an iterative process. But are low-fidelity designs always the best way to go?