I’ve written a post on Sourcing’s blog about structuring Sinatra apps.

I love Sinatra. I use it for practically everything. For me, Sinatra has the perfect blend of simplicity and abstraction. I can understand the full stack, dip into the source when I need to, and extend the framework how I see fit.

However the bare-bones nature of Sinatra can come at a cost. Sinatra leaves much more of the decision making around your application’s structure, layout and libraries up to you. This can be a bit daunting if you’re just getting into Ruby web app development, which I think is one of the reasons why Sinatra is mainly the realm of more experienced developers looking for a bloat-free alternative to Rails.

Read more…

The following part-time positions have been posted within the past week to UMBCworks. Login to your account (via the link in the Jobs & Internships topic in myUMBC) and find details and application instructions as well as hundreds of other job postings!

9263604 - Before & After School Enrichment/Preschool Substitute Teacher - YMCA of Central Maryland
9263432 - Market Research Recruiter - Observation Baltimore
9263507 - Microscopy Training Hub Lab Technician - Hagerstown Community College
9263580 - Part-Time Teacher - C2 Education Centers (Baltimore-Timonium-Columbia locations)
9263504 - Personal Trainer - YMCA of Central Maryland (Catonsville location)
9263489 - Program Assistant in Education - Urban Ecosystem Education - Baltimore Ecosystem Study

The blank slate or “empty state” is when an application has no data. In other words, it’s what an app looks like the first time someone uses it. Not only is the blank slate a critical part of UX, but it can also be used to educate customers and increase their overall happiness with the experience.

The Blank Slate is the First Impression

The first time you use an app, there are no posts, comments, status updates, notifications, or any of the things you might expect in an app that you’ve been using for a while. The first-run experience is when lasting impressions are made, which makes the blank slate one of the most important pieces of UX. It’s an opportunity to educate your customers about how your app works and how it will help them be awesome.

After you’ve been using an app like Facebook for some time, you’ll start to populate it with friends like Andrew.

A great app should make people feel like they can conquer their goals with confidence. While you should provide outstanding customer support, you should also strive to make your app so easy-to-use that customers feel pride in their own self-reliance. The blank slate is your greatest opportunity to educate customers because it’s when they’re the most engaged. They’ve probably just paid you money (or they’re considering paying, in the case of a free trial or in-app purchases) and they want to make sure they’re getting the most out of their hard-earned cash. This is your moment to demonstrate how your app can give them super powers.

Educate Customers in Small Bits

The blank slate should educate (it rhymes, so it must be true) through clear and communicative design. Unfortunately, educating people is difficult. Most customers don’t want to read an instruction manual before they start using a web app or a mobile app, and they shouldn’t have to. They should be able to just get started. This means that a blank slate is more than a single screen. Rather, it’s best constructed as a steady stream of bite sized information that allows them to learn about the app while simultaneously using it to accomplish their goals. Each action should build on the last.

In the sidebar of the Treehouse Forum, there’s guidance about how to get answers and how to get technical help if you need it.

Highlight What’s Unique

When a customer hits your app for the first time, the things that they’ve never seen before will stand out first. Fortunately, these unique features also tend to be the most important parts that make your app special. The design of the blank slate should break down these abstract ideas and imbue them with functional utility so that customers can move on and do great things. Don’t be afraid to add a little extra help text or a small picture in these areas. It’s really important that they get the right idea the first time.

Use Dummy Data

Before presenting the customer with a “blank” screen (which, as we’ve learned, isn’t really blank), it can be helpful to show them what the screen will look like after they’ve used the app for some time. This type of education usually happens in the marketing, before the customer has logged in for the first time. However, after login, it may still be helpful to show a screenshot or an overlay to give them an idea of what the app will look like soon.

This is an image from the Treehouse Features page. In this illustration, potential new students can get an idea of what their profile might look like after they’ve been using Treehouse for a bit.

Make the Next Action Obvious

On a screen with no data, you should tell the customer exactly what they can do to populate that screen with information. This could be as simple as drawing an arrow to an important area of the screen or presenting the customer with a single button that allows them to get started.

Beyond the first-run experience, there might be instances where your application simply runs out of user generated content. In these instances, try your best to anticipate what the customer might want to do next. Give them simple and immediate access to the next action.

Buffer is an app that allows you to schedule upcoming social media updates. If you don’t have any updates in your queue, Buffer makes it easy to add new ones immediately.

Create Helpful Errors

Nothing is more frustrating than zooming through an app and then getting stuck. It will happen sooner or later, so when it does, make sure that your error messages are meaningful and helpful. Identify the issue in plain language and then tell the customer how they can fix the problem or get more help if they need it.

Apple’s 404 page recommends the search functionality. Alternatively, the site visitor can get back on track quickly using one of the site links.

Most often this applies to form validation, but the same concept stands for 404 pages and application errors. If your shiny new app hits a problem, try to recover gracefully by giving the customer some options. Maybe you can help them go back to the previous page, look for help in a customer support forum, or just go back to the home page. As an aside, it’s also a good idea to monitor when these instances occur in your app so that you can fix them quickly.

More Tips

Every app is unique in its own way. If you have a great example of a blank slate or additional tips you’d like to share, let me know in the comments!

The post Tips for Creating a Blank Slate appeared first on Treehouse Blog.

Mark your calendar today for one of the largest job fairs in the area. Co-hosted by UMBC and other colleges and universities in the Maryland Career Consortium. You won't want to miss this excellent opportunity to meet with 100+ employers. Located at the Towson Center at Towson University.

Please note that parking will be very limited, thus FREE shuttle transportation to/from UMBC will be provided.

For parking and fair preparation details and to to RSVP and register to ride the free shuttle bus from UMBC, please click on visit website below.

The following is a guest post by Ara Abcarians (@itsMeAra). Ara is a UX Engineer at Media Temple and worked on the recent redesign of mediatemple.com. Here he shares the ideas, approach, and tech behind that work.

Full disclosure: Media Temple has long given me free hosting. I even use an affiliate link when I link to Media Temple, which I earn a little money from. But I'm not publishing for some backroom shoulder-rubbing reason. I'm publishing it because they did a good job with the redesign, Ara wanted to write it, and I think we all can benefit from his insights on an important large-scale redesign.

Now Ara.

The modern web design and development process is rapidly evolving, and responsive websites are quickly becoming the norm. Frameworks like Bootstrap and Foundation are showing us the value of creating robust systems of components to make building things on the web faster, better, and easier.

About a year ago, I joined LA-based web hosting and cloud services company (mt) Media Temple as a UX Engineer. Tasked with leading the front-end development of (mt)’s website redesign, I took the opportunity to slow down and revisit my front-end development approach. That’s how I realized that the way I was previously building large websites was a little flawed. I wanted to share some of my learning process and shed some light on the high-level approach I chose to take while learning about and building a design system.

But what exactly is a design system?

At FOWA 2013 in London, Mark Otto described a design system as “everything that makes up your product” (see his entire talk here: Build your own Bootstrap).

Everything? Everything. From typography, layouts and grids, colors, icons, components and coding conventions, to voice and tone, style-guide and documentation, a design system is bringing all of these together in a way that allows your entire team to learn, build, and grow.

At first, I wasn’t sure whether I should start building something custom or begin with an existing framework like Bootstrap. Ultimately, I decided against using the latter for a few reasons:

• We already had a custom design. When I started at Media Temple, the visual designs for the new site were just about complete. If I used a framework, I’d have to significantly customize it to fit our designs.
• I wanted to establish coding conventions and structure based on my team’s preferences. Again, I’d have to spend a ton of time re-naming classes or reorganizing things to fit our needs.

The amount of time I would spend essentially gutting the framework didn’t seem worth it. I felt like building our own framework would be beneficial to us in the long run, more maintainable, and, as a bonus, would be an incredible learning experience. It also helped that I had the time to do it, and an entire team that was excited to be a part of it.

Establish Top Level Goals

When rebuilding a legacy website, you're presented with the opportunity to improve a lot of things. Before I began any actual development, I started out by establishing some top level goals:

• Organization: A messy codebase can become a nightmare to work with. Making sure we had a well thought-out structure and approach was very important.
• Maintainability: Over time, there are going to be new developers jumping in to fix bugs and add features. We needed to have proper guidelines and conventions to make it easy for people to do things correctly.
• Responsiveness: Having seen a steady rise in mobile/tablet traffic, it was very important to make the experience platform-agnostic.
• Scalability: The company will grow in the future, and so should its website. Creating promotional pages and/or new product pages should no longer be an unpleasant (and near impossible) task.

My “a-ha” moment

With the top level goals in mind, I started doing extensive research. I began by reading about HTML semantics and front-end architecture and discovered the benefits of building flexible modules, not pages. That was my “a-ha” moment.

Previously, while building large websites, I was used to dividing the work by page templates. I’d tackle a set of related templates, then move on to another set. The problem with this approach is that, if the communication between the team isn’t exceptional, you’ll end up with many similar — sometimes identical — modules and components marked up and styled in different ways. If you don’t spend the extra time refactoring them, your codebase will turn into an absolute mess.

I decided to study two excellent — but different — projects very deeply: InuitCSS by Harry Roberts and Bootstrap by Mark Otto and Jacob Thornton, and I quickly realized the next step I needed to make was to establish guidelines around how our HTML, CSS, and JavaScript should be coded and what our overall front-end approach should be.

Coding Conventions and Guidelines

Inspired by Idiomatic HTML, CSS Guidelines, and Idiomatic JavaScript, I began adapting these into our own set of coding guidelines. In the process, I discovered and adopted an interesting naming methodology called BEM (Block, Element, Modifier). It’s essentially a clever way of naming your CSS classes to make them more meaningful and simpler to understand.

Our slightly modified convention is:

• .block {} - Represents the main component.
• .block-elementName {} - A child element that helps make up the component as a whole.
• .block--modifier {} - A modifier class that is used to alter the state or appearance of the component.

Here is an example of an alert box using this approach:

/* Main 'alert' component */
    .alert {}
    
      /* Sub-components that make up the 'alert' */
      .alert-text {}
      .alert-close {}
    
    /* Modifiers for various styles of the 'alert' */
    .alert--warning {}
    .alert--error {}
    .alert--success {}
    .alert--info {}

I also finalized a set of tools to help us along the way, including LESS for our CSS pre-processing needs, and Grunt to compile our LESS files and compress, minify, and concatenate our code.

Developing Base Styles

Similar to InuitCSS and Bootstrap, I created a primary stylesheet called mt-global.less which would import all of the site styles together and create the final mt-global.css file. In an effort to keep things organized, I created a few folders:

• core - This would hold our custom variables and mixins.
• vendor - For vendor utilities used, such as LESSHat and REMixins.
• base - For all of the underlying base styles like typography, colors, and structure.

I started out with normalize.css, adapting it as needed, and continued styling general elements such as headings, links, lists, form elements, and tables.

Identify and Build Components

With the base styles in place, it was time to take a look at the website as a whole, and start identifying individual components. I started building a custom grid system based on the grid used for the designs. From there I continued on to common elements like buttons, call to action links, hero units, and navigation.

As I was building components, I started figuring out ways to abstract common styles into reusable objects, similar to the media object. InuitCSS was a huge help here as it contains tons of useful objects. All of these styles were put into folder called components.

Identify and Build Modules

With most of the components ready to go, it was time to use these building blocks to create each page’s various modules. I created another folder called modules, and began putting them together, starting with global modules like the site header, footer, and hero unit.

Establishing Patterns

As I was building components and modules I started to plug them into a style guide using the Style-Guide Boilerplate. The result was a single point of reference for any team member interested in learning how to contribute to the website. Once the whole team had access to the style guide, building page templates was a breeze. It was just a matter of mixing and matching modules, and extending or customizing them when necessary.

In Conclusion

Building a design system is a long process filled with trial and error. Established frameworks can save you weeks of development time, but if you’ve built your web project with a framework that has since gone through many releases, maintaining it can be difficult. Do you upgrade your codebase with each release? What if you have customized it so much that updating it isn’t even an option?

If you have the opportunity to rebuild a site from the ground up, building a custom solution solves a lot of issues: It helps establish a custom tailored system enabling your entire team to quickly and easily learn how to contribute to your project; it’s built by you and specifically for your company’s needs; and, most importantly, it’s built for the future. Without being tied down to another project’s evolution and direction, it’s free to scale at your companies pace.

Research. Build. Learn. Repeat.
- John Polacek

Above all, it was an incredible learning experience and a great source of pride for our team. I encourage everyone to study the many resources available about design systems and the ever changing web design process.

Design Systems: Building for the Future is a post from CSS-Tricks