Posted On September 18th, 2011 Author Kyle Racki
Filed Under Design, Business, Development, 1
Just recently, a big change came along in web design; Arguably the biggest revolution since modern web standards in the early 2000's.
Responsive Design has been invented. It's a term used in new age architecture to describe buildings that behave 'responsively'. That is, they adapt or respond to conditions such as the amount of people in a given room, for instance. They will automatically change heat, air and even room size (yes, the walls expand and contract!) to accommodate more or less people.
And just like Responsive Design in architecture, when it comes to the web, responsive design allows websites to no longer behave like static online brochures that scroll, but rather they adapt by expanding and contracting, resizing themselves to appropriately fit a variety of screen sizes. So for example, a website might have five columns when viewed on a 52" wide screen, but when viewed on a laptop it may scale down to three columns, two on an iPad and down to one column when viewed on a smart phone.
The best way to illustrate this is by viewing this gallery of well-designed responsive sites. You'll see four views for each site, from wide screen down to a small screen. Pretty impressive, huh?
The best part is, designing sites to be responsive does not add a lot of size, scope or complexity to a project. Sure, it adds some work for the designer and developer. But really in the grand scheme of building a website from start to finish, building it responsively is not all that time consuming once you know how.
Now, like all things in life, there's a catch. Building a website with responsive design is not a replacement for a mobile app or site. There are subtle but key differences.
Depending on your business, you may find that you actually need a mobile web application instead of just a website that scales to a variety of devices and screen sizes. The reasons are:
-
Functionality
-
Weight
-
Business Model
1) Functionality
The trick with responsive is that it's all in the layout. When a user is on a smart phone, they are looking at the exact same site as on a desktop computer, but the CSS or style sheet is scaling the site visually to look better on a mobile device. It's kind of like window dressing. The HTML page is exactly the same.
Now you may find that on a mobile device, you want to do more than simply make the website look different. You actually want to take advantage of a mobile device' hardware. You may want to let the user shake their phone to randomize a search, upload photo's through their phone camera, plot their location through GPS. These are things you'll actually have to build specifically for the mobile device - you obviously don't want this functionality for users on a desktop!
There may also be a lot of functionality on your main website that you want simplified and altered significantly on the mobile experience. If you have an iPhone, think of how different the main Facebook website is from the iPhone app version of Facebook. On the latter, the functionality is simplified significantly from how you would use it on the website (no instant messaging for example).
An added benefit of mobile websites is that you can include a link at the bottom of the site "Click here to leave the mobile version". This way, you can present your user with choice so they default to the mobile version, but can always load the desktop version on their phone if they so choose.
2) Weight
With responsive, again, the HTML page is exactly the same regardless of what device you're viewing it on. On a mobile device, every bit of information a user has to download counts - because users often have slower internet connections and their phones have less memory than a desktop computer.
So if your main website has a lot of intensive graphics, videos, and sounds that a user has to download, responsive design is not going to change that when the user is viewing it on a smart phone. A mobile web app on the other hand is a completely different site, made specifically for phones, and there are a lot of techniques developers can employ to make the page as fast and lightweight as possible.
I won't get too much into the technical stuff here, but it would include using HTML5 local storage techniques, limiting the amount of http requests, keeping Javascript libraries as compressed and minimal as possible, loading smaller images and a whole lot more.
3) Business Model
If you have a blog, chances are your website will be used the same way regardless of what device you're user is accessing it with. Blog's are always for finding and reading content, and sometimes commenting on a post. In that case, responsive design is probably a perfect solution, since it allows the content to be optimally viewed on a phone.
Now on the other hand, if your website involves a lot of user functionality, like the aforementioned Facebook, which includes adding photos, tagging pictures, posting content, finding friends and more, it's much better to design a specific mobile experience that varies greatly from the desktop experience.
And you don't have to be as big as Facebook either. There are a lot of companies whose desktop websites wouldn't translate well as merely a shrunken down mobile version, but would benefit from a true mobile app. Some examples may be banks, movie theatres, restaurants, concert venues, e-commerce stores, social sites... the list goes on.
The other factor to consider too is whether or not you want to sell your app and/or make it available on the iTunes Store or Android Marketplace. If you do, responsive is not going to work. On the other hand, you could make a native iPhone/iPad/Android app, OR build a mobile web app using open standards and using the insanely clever PhoneGap, you can package your web app as if it is a native app. This will enable you to use the phone hardware like contact lists, voice and camera, and will also allow you to sell it on app stores.
Closing thoughts
As a general rule, I like to think of it like this: If your website is meant to be viewed, Responsive Design is an amazingly simple technique to please visitors on your site (in fact, I think that building in Responsive is the first place every company should start when they want to dip their toes in the mobile landscape).
On the other hand, if your website is primarily meant for users to interact with (games, accounts, videos, social, e-commerce etc.) then a mobile web app is an important investment worth making.
Posted On August 18th, 2010 Author Kyle Racki
Filed Under Development, 3
It’s been a long time coming, but ExpressionEngine 2 is finally here, and after using it on a number of projects, I can say that it was worth the wait.
This is not meant to be an in depth post, but merely a few points that I especially enjoy about the new EE. Because some of the features are more technical in nature and not necessarily of great interest to end users (our clients) I want to separate the points into those two categories; Clients and Developers:
Clients
Better Control Panel - The actual CMS looks a lot better than EE 1 (hey, Ellis Labs even seemed to brand it with the Headspace hot pink. Good taste I guess). Above and beyond just aesthetics, the new control panel is actually easier to use. There is more use of AJAX effects and JQuery enhancements, which means less rooting around and clicking on multiple nested links to get to where you want.
File Management and Uploads - I can admit it - uploading and managing images and other files, and then inserting them into posts was painful for clients in the old EE. Now it couldn’t be simpler. I can now create custom fields in the admin as upload fields, so the upload/browse function exists right where it makes sense - even cropping and resizing right there with no hassles. There is a simple file management tool, where you can easily see all of the files on the server, and you can view/edit/delete them with only a few clicks.
Complete CodeIgniter Compatibility - OK, this point probably belongs in the developer heading, but then I thought about it; This serves end clients as much as it does developers. For those who don’t know, CodeIgniter is a popular, free, open-source PHP framework that Ellis Labs created for developers to rapidly build custom web applications with. Unlike EE1, the new ExpressionEngine is actually a product of CodeIgniter, being directly built off of the platform (When you download EE, you are actually downloading CodeIgniter with an ExpressionEngine folder inside it). What does this mean for clients? More back-end power and flexibility so developers can create more customized functionality within ExpressionEngine, and make it behave like a true web application. There is virtually nothing you could need on the web that EE can’t do for you.
Developers
Snippets - Common repetitive blocks of content or code that appear through your site used to be managed with embedding templates in EE1. That meant more database queries and slowed down your site if you weren’t careful and selective. Snippets allows me to place common blocks of code (PHP, ExpressionEngine tags, or just static markup/CSS/JS) within a snippet and include that whenever and wherever I feel like it. It is not included like the templates, it actually just becomes part of the page when loaded, using no database queries - thus allowing me to work more efficiently, write less repetitive code, and still keep sites light and fast.
Template Saved as files - This feature was technically possible in EE1, but I could never seem to get it to work right. In EE2, it is easy to sync templates to HTML files on your server. Instead of fumbling through templates in the control panel and updating the database each time I make a small edit, I can now just work remotely off of HTML pages in my favorite coding editor (Coda) and just save them when complete, just as if I was coding a static website. Collectively, this saves maybe hours of time on a project and is much more enjoyable to work.
These are just a couple of things I wanted to note about ExpressionEngine (I promise they are not sponsoring Headspace). It’s nice to have more firepower in our back pocket, and I look forward to getting into EE2 more over the coming weeks and months.
Posted On March 18th, 2010 Author Kyle Racki
Filed Under Business, Development, 0
Many of the web projects that we bid for specify in their RFP that the vendor must build with web standards as specified by the W3C. However, in the past, some of our clients have wondered why sites we produce do not always validate, and some clients have even been challenged by losing bidders that they apparently made the wrong choice in a web partner. We were once even told that because a website didn’t validate, it would not rank highly in search engines!
The attempt of this post is to set the record straight and dispel the myth that web standards and validation are the same thing (though they are closely related).
Without getting into the intricacies of web standards, it is important to note that web standards have been devised by the W3C to separate content, presentation and behavior. HTML tags are “marked-up” around textual content in a semantic manner (using tags to describe the meaning and format of the content), and in a separate file, CSS is used to instruct the HTML how to look (ie: fonts, colours, layout etc.). For a more detailed, but completely simple and comprehensible explanation of web standards, see the post on Boagworld.
The W3C offers a validation service for free that will automatically scan a web page for inappropriate HTML tags. This makes sure that critical things like missing closing tags are spotted and corrected by the web developer. Validation is very useful and an important check to make before launching a website, but is it the same as building a site with web standards?
Remember that the ‘wrong’ way of building websites was often with HTML tables for layout, image tags for headings, and inline style-sheets. The ‘right’ way is with semantic HTML separated from presentation code. However consider this; You can build the old way, and your page will still validate, as long as your tables are correctly written, your image tags have alt attributes specified and your inline style-sheets are correctly formatted. So for anyone who says validation is some sort of certification or that it is official “proof” that a website is built to standards—the validator would in effect be approving a badly constructed website, and incorrectly stating it is built to standard.
Conversely, a properly coded, web standards-compliant website may be missing an ALT attribute on an image (which basically describes the image to users who have images disabled in their browser). Or the parameter that opens a link in a new window (target=“_blank”) may be in use. Because of these minor offenses, the web page generates validation errors. Should the errors be corrected? Probably, but sometimes it is the lesser of two evils to use degraded tags that break validation, while keeping the intended functionality of your website. (For all you geeks out there; I know you can use javascript to open links in a new window, but it’s not my point. Once a website is in a CMS, clients will often add images with ALT, or use the target parameter, in which case it’s out of your hands).
The point is, a non-standards based website may validate, while a beautifully coded, standards-based website may not validate. Validation is a best-case-scenario checklist, and not the be-all-end-all decider or whether or not a website was built with web standards.
Posted On April 2nd, 2009 Author Kyle Racki
Filed Under External Articles, Business, Development, 3
View the original post here: 10 criteria for selecting a CMS
I like all of Paul’s choices for the post, including:
Multi site support
We’ve had a few instances come up where our clients have multiple websites all running off the same server. In these case, having a CMS that let’s you edit content across multiple sites from the same admin login is invaluable.
Roles and permissions
Whenever I set up a website for clients to edit themselves, there’s always some work involved in making it a pleasant experience for them. With different levels of permission, I make sure that while my Super Admin account has all of the bells and whistles that I need for development, the client’s account is significantly simplifed to make it easy for them, and also avoid the chances of them accidentally deleting everything!
User interaction
Modern sites almost always require some sort of user interaction, whether it’s filling out a contact form or adding a comment to a blog. How easy does the CMS make it to gather, store and view the data?
Managing assets
In many cases, clients need to upload images, PDF, and video files through their site. How easy is it for them to store and use the content?
These are all great points Paul made, but I have two more of my own I’d like to make:
Markup generated
Something I hate about many CMS’s is the HTML they generate. It’s frustrating to design and develop a standards based site with clean, semantic markup, only to have a content management system to spit out nested div tags with unintelligible class names like “node-21”. This sometimes can mean that your design is dictated, not by user testing or skilled designers, but the back-end code that makes the content editable.
Wake up CMS developers! The CMS should just control what flows out of the database, not what the users sees and interacts with. This is one of the reasons we love Wordpress and ExpressionEngine. Utilizing their powerful loop, it generates data and let’s you wrap it in any sort of markup you want.
Open Source vs Proprietary
This is a controversial topic, but the bottom line is this: Open source CMS’s are free to download and use, built by a community of developers. The downside is that if the CMS doesn’t have a large following, there is no one to support it, and also you don’t have a tech support phone number to call if you need help.
On the other hand, proprietary CMS’s are developed and owned by a commercial company. Some like this option because they can speak directly to the company for support and to feel taken care of. However in many cases, there is the risk of the company going under, in which case, you have to rebuild your site if you want upgrades. Also, I find that proprietary systems are more limiting than open source, simply from the fact that open source projects are built by a large community, and companies are limited to their staff.
What about you, do you have any other factors to consider when choosing a CMS?
Next Page