joshwhatk
Ancora imparo.
-
from Smashing Magazine Feed
In my nearly two decades as an information architect, I’ve seen my clients flush away millions upon millions of dollars on worthless, pointless, “fix it once and for all” website redesigns. All types of organizations are guilty: large government agencies, Fortune 500s, not-for-profits and (especially) institutions of higher education.
Worst of all, these offending organizations are prone to repeating the redesign process every few years like spendthrift amnesiacs. Remember what Einstein said about insanity? (It’s this, if you don’t know.) It’s as if they enjoy the sensation of failing spectacularly, publicly and expensively. Sadly, redesigns rarely solve actual problems faced by end users.
I’m frustrated because it really doesn’t have to be this way. Let’s look at why redesigns happen, and some straightforward and inexpensive ways we might avoid them.
The Diagnostic Void
Your users complain about your website’s confounding navigation, stale content, poor usability and other user experience failures. You bring up their gripes with the website’s owners. They listen and decide to take action. Their hearts are in the right place. But the wheels quickly come off.
Most website owners don’t know how to diagnose the problems of a large complex website. It’s just not something they were ever taught to do. So, they’re put in the unfortunate, uncomfortable position of operating like country doctors who’ve suddenly been tasked to save their patients from a virulent new pandemic. It is their responsibility, but they’re simply unprepared.
Sadly, many website owners fill this diagnostic void — or, more typically, allow it to be filled — with whatever solution sounds best. Naturally, many less-than-ethical vendors are glad to dress up their offerings as solutions to anyone with a problem — and a budget. The tools themselves (search engines, CMS’, social apps) are wonderful, but they’re still just tools — very expensive ones, at that — and not solutions to the very specific problems that an organization faces. Without proper diagnostics to guide the configuration of tools, any resulting improvements to the user experience will be almost accidental.
Sometimes design agencies are brought in to fill the diagnostic void. And while not all agencies are evil, a great many follow a business model that depends on getting their teams to bill as many hours as they can and as soon as possible. Diagnostics can slow the work down (which is why clients rarely include a diagnostic phase in their RFPs). So, many agencies move to make a quick, tangible impression (and make their clients happy) by delivering redesigns that are mostly cosmetic.
A pretty face can last only a few years, but by then the agency is long gone. Invariably, the new owner wishes to make their mark by freshening or updating the website’s look. And another agency will be more than happy to oblige. Repeat ad nauseam, and then some.
Oh, and sometimes these redesigns can be pricey. Like $18 million pricey.
See why I’m so grouchy?
Forget the Long Tail: The Short Head Is Where It’s At
Whether you’re a designer, researcher or website owner, I’ve got some good news for you: diagnostics aren’t necessarily difficult or expensive. Better yet, you’ll often find that addressing the problems you’ve diagnosed isn’t that hard.
And the best news? Small simple fixes can accomplish far more than expensive redesigns. The reason? People just care about some stuff more than they care about other stuff. A lot more. Check this out and you’ll see:
This hockey-stick-shaped curve is called a Zipf curve. (It comes from linguistics: Zipf was a linguist who liked to count words… but don’t worry about that.) Here it is in dragon form, displaying the frequency of search queries on a website. The most frequently searched queries (starting on the left) are very, very frequent. They make up the “short head.” As you move to the right (to the esoteric one-off queries in the “long tail”), query frequency drops off. A lot. And it’s a really long tail.
This is absolutely the most important thing in the universe. So, to make sure it’s absolutely clear, let’s make the same point using text:
Query’s rank Cumulative % Query’s frequency Query 1 1.40% 7,218 campus map 14 10.53% 2,464 housing 42 20.18% 1,351 web enroll 98 30.01% 650 computer center 221 40.05% 295 msu union 500 50.02% 124 hotels 7,877 80.00% 7 department of surgery In this case, tens of thousands of unique queries are being searched for on this university website, but the first one accounts for 1.4% of all search traffic. That’s massive, considering that it’s just one query out of tens of thousands. How many short-head queries would it take to get to 10% of all search traffic? Only 14 — out of tens of thousands. The 42 most frequent queries cover over 20% of the website’s entire search traffic. About a hundred gets us to 30%. And so on.
It’s Zipf’s World; We Just Live in It
This is very good news.
Want to improve your website’s search performance? Don’t rip out the search engine and buy a new one! Start by testing and improving the performance of the 100 most frequent queries. Or, if you don’t have the time, just the top 50. Or 10. Or 1 — test out “campus map” by actually searching for it. Does something useful and relevant come up? No? Why not? Is the content missing or mistitled or mistagged or jargony or broken? Is there some other problem? That, folks, is diagnostics. And when you do that with your website’s short head, your diagnostic efforts will go a very long way.
The news gets better: Zipf is a rule. The search queries for all websites follow a Zipf distribution.
And the news gets even jump-up-and-down-and-scream-your-head-off better: Zipf is true not only for your website’s search queries. Your content works the same way! A small subset of your website’s content does the heavy lifting. Much of the rest has little or no practical value at all. (In fact, I’ve heard a rumor that 90% of Microsoft.com’s content has never, ever been accessed. Not once. But it’s a just a rumor. And you didn’t hear it here.) Bottom line: don’t redesign all of your content — focus on the stuff that people actually need.
You’ll also see a short head when it comes to your website’s features. People need just a few of them; the rest are gravy.
And there’s more. Of all the audience types that your website serves, one or two matter far more than the others. What tasks do those audience types wish to accomplish on your website? A few are short-head tasks; the rest just aren’t that important.
As you can see, the Zipf curve is everywhere. And fortunately, the phenomenon is helpful: you can use it to prioritize your efforts to tweak and tune your website’s content, functionality, searchability, navigation and overall performance.
Your Website Is Not A Democracy
When you examine the short head — of your documents, your users’ tasks, their search behavior and so forth — you’ll know where to find the most important problems to solve. In effect, you can stop boiling the ocean…
… and start prioritizing your efforts to diagnose and truly solve your website’s problems.
Now, let’s put these short-head ideas together. Below is a report card for an academic website that starts with the short head of its audience:
In other words, of all the audience types this university website has, the three most important are people who might pay money to the university (applicants,) people who are paying money now (students) and people who will hopefully pay money for the rest of their lives (alumni). How do we know they’re the most important audiences? We could go by user research; for example, the analytics might suggest that these audiences generate more traffic than anyone else. Or perhaps the university’s stakeholders believe that these are the most important ones in their influence and revenue. Or some combination of both. Whatever the case, these three audiences likely swamp all other segments in importance.
Then, we would want to know the short-head tasks and information needs of each audience type. We might interview stakeholders to see what they think (column 2). And we might perform research — user interviews and search analytics, for example — to find out what users say is most important to them (column 3).
Of course, as the good folks at xkcd demonstrate, stakeholders and users don’t always see things the same way:
That’s why talking to both stakeholders and users is important. And once you’ve figured out the short head for each, you’ll need to earn your salary and, through some careful negotiation, combine your takes on each audience type’s needs. That’s what we’ve done in column 4.
Finally, in column 5, we’ve tested each task or need and evaluated how well it works. (Because it’s a university-related example, letter grades seemed appropriate.) You can do this evaluation in an expensive, statistically significant way; but really, enough research is out there to suggest that you don’t need to spend a lot of time and money on such testing. More importantly, these needs and tasks are often fairly narrow and, therefore, easy to test.
So, after testing, we can see what’s not going well. Finding information on “mentoring” is hard for applicants. And current students have a devil of a time when they “look up grades.”
Now we’re done diagnosing the problems and can begin making fixes. We can change the title of the “Paired Guidance Program” page to “Mentoring.” We can create a better landing page for the transcript application. The hard part, diagnostics, is out of the way, and we can now fix and tune our website’s performance as much as our resources allow.
From Project To Process To Payoff
These fixes are typically and wonderfully small and concrete, but because they live in the short head, they make a huge and lovely impact on the user experience — at a fraction of the cost of a typical redesign.
The tuning process itself is quite simple. It’s what we used to arrive at the report card below:
If you repeat this simple process on a regular basis — say, every month or quarter — then you can head off the entropy that causes fresh designs and fresher content to go rotten. Thus, the redesign that your organization has scheduled for two years from now can officially be canceled.
Your website’s owners ought to be happy about all this. And you should be, too: rather than tackling the project of getting your website “right” — which is impossible — you can now focus on tweaking and tuning it from here on out. So, forget redesigns, and start owning and benefiting from a process of continual improvement.
Special Thanks – Illustrations
Eva-Lotta is a UX Designer and Illustrator based in London, UK where she currently works as an interaction designer at Google. Besides her daytime mission of making the web a more understandable, usable and delightful place, she regularly takes sketchnotes at all sorts of talks and conferences and recently self-published her second book. Eva-Lotta also teaches sketching workshops and is interested in (something she calls) visual improvisation. Exploring the parallels between sketching and improvisation, she experiments with the principles from her theater improvisation practice to inspire visual work.
(al)
© Louis Rosenfeld for Smashing Magazine, 2012.
-
from Smashing Magazine Feed
There is an aspect to Web design that no one likes to talk about: spec’ing. We all do it, we all hate it, but we also understand that specs are vital to both designers and developers.
For those who aren’t familiar with the term in this context, “specs” is short for specifications — in the case of design, they are instructions that specify colors, fonts, sizes, spacing and so on, just like a blueprint. Specs are a crucial part of the design and development process for companies with big teams and for small companies that have to outsource some of their development. Specs function not only as instructions to developers, but also as a reference point to make sure the whole team is on the same page.
However, the process of producing specs is repetitive and time-consuming, especially for creatives. But now this can all change: Specctr, together with Adobe Fireworks, offers a quick and easy way to generate this important information automatically.
The Idea
My idea to make Specctr came from my personal experience working on a design team at a large corporation. Spec’ing was part of my routine. One day, after hours of spec’ing, my eyes hurt and I was bored and frustrated. Suddenly, I realized that this kind of intensive work should be automated, and that a designer’s time is much better spent designing rather than spec’ing.
Specctr is more than a tool: it is a business solution for any company whose designers must generate specs for developers. Specctr facilitates this communication and leaves designers and developers happier and more productive. Making this process quicker frees up the business to focus more intently on its core mission.
Possible time saved using Specctr for Adobe Fireworks.
Time saved using Fireworks and Specctr Pro.In the process of creating Specctr, I brought my design background and practical experience in spec’ing to bear on the issues and opportunities in automating the process. Meanwhile, my colleague, Dmitriy Fabrikant, engineered the software from the ground up. Working in tandem at On Pixel, we released Specctr Pro in January 2012. Since then, it has received many favorable reviews.
Specctr Lite
In addition to the commercial version of the tool, we’re happy to release a free version called Specctr Lite as a contribution to the community. We chose to highlight width and height as well as text spec’ing abilities, because they are most common to a designer’s workflow. These two feature sets alone will save a lot of valuable time.
The Lite version includes:
- Width and height
- Text spec (font family, size, color)
- Expand canvas feature
Specctr Lite can be downloaded for free from our website, and we’re happy to say that it was created and released as a result of the involvement of Smashing Magazine!
Pro and Lite: a quick comparisonThe Lite version is as easy to use as the Pro version, and its features work the same way.
Requirements And Installation
To use Specctr (Pro or Lite), you need:
- A Mac or PC
- A copy of Adobe Fireworks CS3, CS4, CS5 or CS5.1
The installation process is pretty straightforward:
- Download the Specctr installer
- Double-click the MXP file to open the Adobe Extension Manager
- Click on “Install”
- Restart Adobe Fireworks
- In Fireworks, go to
Window → Specctrto open the Specctr panel.
Please note: If you are using Windows Vista or 7, you might need to launch the Adobe Extension Manager as Administrator, otherwise the extension could fail to install.
If you still have questions, don’t hesitate to consult our online tutorial (PDF, 1.9 MB) or contact us directly!
Specctr Pro
A Brief How-To Guide
Once you install Specctr through the Adobe Extension Manager, restart Fireworks, and then open Specctr from the
Windowmenu. Now that Specctr is open, you can spec a document in a few easy steps.First, prepare your document by making room for your specs. Select the size of your design’s border, and click on the “Expand Canvas” button.
Select which details to display by toggling them on or off from the panel’s menu.
Now Specctr Pro will automatically display your spec with a click of the button.
To spec a shape (shape, line, dot, etc.) or a text object, select the object (or multiple objects), and click on the “Spec Object” button. The specs will be outputted to the nearest edge of the canvas.
Properties of objects in a specYou can also spec the spacing between two objects by selecting them and then clicking the “Spacing” button. If you select only one object, Specctr will measure the object’s distance to the edges of the canvas.
Measuring the space between objectsFinally, you can also spec the width and height of any object.
Insight Into The Fireworks Extension Development Process
The process of developing Fireworks extensions consists of the following steps:
- First, we design and build the panels in Adobe Flash Pro.
- We import the panels into Flash Builder and add the ActionScript code, which makes them run.
- Finally, we have to connect with the Fireworks API, which is written in JavaScript, in order to manipulate Fireworks.
Because the development process is spread over three separate environments, integrating the different pieces of the application and debugging the application present some challenges. But in the end, it’s well worth the positive response from our users.
In the next couple of weeks, Dmitriy will release on GitHub a few ActionScript libraries that he has built during the process of developing Specctr. These libraries will hopefully reduce some of the pain points of the tiered development process. We might also write another article that highlights in more detail the development process for building a Fireworks extension.
One of Fireworks’ strengths is its potential as a development platform that leverages the creativity and innovation of its community. We would love to help this process and show that Fireworks is a powerful tool for Web design.
Further Reading
Here are a few useful resources related to extending Adobe Fireworks:
Extensions
- Aaron Beall
- John Dunning
- Matt Stow
- Orange Commands, Ale Muñoz
Other Resources
- Extending Fireworks blog, Grady Kelly
- Extending Fireworks, Fireworksguru Forums
- “Creating Fireworks Panels, Part 1: Introduction to Custom Panels,” Trevor McCauley, Adobe Developer Connection
- “Extending Adobe Fireworks CS5” (PDF), Adobe Product Support
(al) (mb)
© Chen Blume for Smashing Magazine, 2012.
-
from 1stwebdesigner
If this message appears to another site than 1stwebdesigner ,it has been stolen, please visit original source!
In the span of 6 years I’ve seen new blogs become successful and more than too much fell into oblivion. Right now the only blogs that are successful will probably be the only ones to hold the stage for a long time, bad news for newcomers. There are a lot of reasons why blogs fail, and it begins at conception!
Blogging is about sharing things you are good at, or at least you’re enthusiastic about. Whether you are a web designer, web developer, a writer, an online marketer, or someone else who doesn’t have a blog yet, or has one but has failed quite miserably, then you definitely need to know why it failed (and why it will fail).
But hold your horses, I’m not saying you should stop blogging!
You can leave it to self-discovery and fail or I can point them out for you and increase your chance of succeeding.
Whether you are new to blogging or is planning on starting one, the problems highlighted here are serious enough to threaten your blog’s success. That’s why I have written several tips to avoid failure!
Already have a failing blog? See number 3!
5 Reasons Why Blogs Fail
1. Premature Launch
Perfect, your blog is now live…but do you have an audience? Four days after launching my blog, Knowledge Salad (shameless plugging detected!), I was already averaging 30 visitors daily. Not bad, I should say. Better than zero, right? How did I do it?
- Write tons of articles/posts for your blog before launching. Before I launched my website I have already 25 posts waiting to be published. You don’t want to launch it with just one blog post. Okay, what’s the difference between articles and posts? Well, let’s just say that posts are the raw form of spur-of-the-moment writing, like saying hi to your readers or giving an update. An article would be one that has been researched thoroughly and heavily proofread and edited.
- I forced my blog’s Facebook Fan Page to my friends. I have few friends on Facebook, and I only contacted around 40 of them. You know how the newsfeed goes, when a friend likes something it shows on a friend of friend’s newsfeed (you following me?), then that’s where the numbers blow. Right now I only have 114 subscribers. In my defense, I stopped marketing and forcing it to people, haven’t updated my blog yet for a long time now. In any case, ask your friends for help!
- Contact relevant blogs and write for them, even for free. In my case I have already joined 1WD. A lot of blogs will certainly give you a byline where you can link directly to your blog. Here’s the crucial part, if you’re not yet ready to launch it, so that it won’t be a premature launch, you should have a splash page where you can start gathering emails. Tell them that “Rean is currently brewing some materials to help you earn more by writing!” or something to that effect, and “sign up to be notified when the site goes live!” A.K.A. list building! This way when you launch your blog, you will already have an audience.
- Once you have written for a lot of authoritative blogs, and have made good relationships with them, you probably can ask for favors. A shout out on Twitter or Facebook or even a post itself from them. This is the good thing about the blogging community, it’s all about give and take.
2. Introvert Blog
A lot of new bloggers tend to just focus on their blogs, not knowing that they won’t have a good amount of audience without proper marketing. Marketing is quite a heavy word, and it entails longer period of work than the blog post itself. This is where the following comes in to help you gather enough audience and increase the chance of your blog’s success:
- Use Social Media. You should know how to leverage Facebook and your friends (and your friends’ friends), Twitter marketing, Pinterest, and Google+, Reddit, and a lot more.
- Enable email subscription. See point 1.1 about gathering emails. Email marketing is very important!
- Join online communities/forums. For small to medium blogs, I’d suggest joining Blog Catalog. There are thousands of bloggers there that would gladly help you improve your blog. You can ask for tips, and in return provide valuable content for them to enjoy.
- Respond to comments. Nothing shuns away readers more than a non-responsive author. They might think that your blog is just another aggregator or a robot that publishes posts. Having a human connection is important! Dainis, founder of 1WD, actually insists on replying to every comments!
3. Hoarding Posts
Don’t keep everything for yourself. Your blog might be too plump and puffy but your traffic is severely malnourished. And you are wondering why? I’d love to break it to you: don’t hoard all the posts you have written. Find blogs relevant to your niche and ask them if you could submit posts to them for publishing.
Danny Iny, the Freddy Krueger of Blogging, mentioned in one of his webinars that you should only write maybe four to five posts a month on your blog if it receives less than 250 visitors a day, then spend the rest of your time guest blogging to get the word out that you have your blog and that people should visit it.
If you want to make your blog successful, you should spread your wings and make your presence known. Contact blogs that have high authority in their niche and join them. This way you’ll be noticed!
Guest post, guest post, guest post!
4. Fear of Learning
If you have a blog, or is thinking of starting one, you should have at least a basic understanding of how the internet works. I’d go as far as to say that it is required. You will thank me for saving you in the wee hours of the morning when your blog suddenly stops working just because of a faulty plugin and your tech savvy friend is still sleeping.
You won’t go far if:
Someone had to do it.
- You don’t know how to tweak your blog’s design, hence you’re left flailing like Magikarp when an IT friend is nowhere to be found.
- You don’t know how to install a plugin or a theme.
- You are too afraid of changing hosts.
- You don’t know a lot about the internet.
- You are too afraid of experimenting.
You should probably start learning a few useful things like CSS, HTML, and some WordPress hacks if you’ll use WordPress CMS.
5. Don’t Know Where to Start?
Since I joined 1WD I have received hundreds of emails asking for instructions on how blogs are created. Some even thought that 1WD is a web development firm.
Here’s a complete guide on how to create a blog in under 1 hour, all the technical aspects explained!
Do you have a successful blog? Share your tips!
Hopefully, you will never have to ask yourself why blogs fail after reading this!
-
from Smashing Magazine Feed
You cannot plan for and design a responsive, content-focused, mobile-first website the same way you’ve been creating websites for years—you just can’t. If your goal is to produce something that is not fixed-width and serves smaller devices just the styles they require, why would you use a dated process that contradicts those goals?
I’d like to walk you through some problems caused by using old processes with responsive design. Let’s look into an evolving design process we’ve been using with some promising new deliverables and tools. This should provide a starting point for you to freshen up your own process and bring it into the responsive age.
The Problem
The issues caused when trying to force new results from an old process are significant yet, strangely enough, not immediately obvious. We’ve all just gotten used to them, like the annoying quirk we didn’t realize we had, until someone points it out. And from that point forward, it drives you crazy. For example, when we create a desktop-sized, fixed-width site layout in Photoshop and hand it to a developer to interpret into HTML/CSS, we are asking the developer to make a lot of design decisions—possibly without even realizing it. Below is just a small sample:
- How should the layout adjust for smaller-sized devices? (It sure would be nice to have a hierarchy of important page elements based on their purpose, huh?)
- What is the hierarchy of the content? (Gee, all that “Lorem Ipsum” doesn’t make it obvious?)
- How does the navigation respond to smaller screens? (How do I handle ten links with five child pages each revealed on hover with a 320×480 touch device?!)
This can cause major problems if the developer doesn’t feel confident in the visual arena. Even designers/developers who feel comfortable making those calls can get in hot water. In the end, the developer is often forced to make assumptions where plans were not made clear beforehand—sometimes days before feedback from designer or client becomes available. Sometimes it works, sometimes it doesn’t.
Work More or Work Efficiently?
It’s easy to resort to working more to resolve these new challenges. What comes naturally? Do a desktop and mobile-sized wireframe, then turn around and design a desktop and mobile-sized layout. This sort of solves the problem. You and your developer have more to work with, at least. However, what about all the device widths in-between—you’ll have to cover those as well, right?
At this point, you wake up and realize you’re stuck in a familiar loop of ever-increasing deliverables and ever-shrinking profits. Using this old process to tackle new problems doesn’t really solve any of them, and it’s going to kill you from lack of sleep, make you poor from lack of profit, or both.
There are some good ideas floating around dealing with new processes. Some smart folks are of the very sensible opinion that the only answer is to design in the browser. However, other smart folks have admitted for the quiet rest of us that it’s really, really hard to design freely in the browser—at least with current tools.
Of the emerging new process ideas, those that involve responsive HTML/CSS prototypes look very promising. I’m planning to investigate these further. However, there are some definite challenges with this approach, not the least of which is the time it takes to create them when the site content is complex. Most of the examples I’ve seen are fairly generic, which doesn’t translate well to real projects.
Currently, we are successfully using a different approach. It attempts to optimize content, design, and development time, finding a budget-friendly balance of appropriate direction from all disciplines—something that is effective, lean and uses quick, widely-accessible tools.
Solution: The Priority Guide
I used to call this my “mobile-sized content prototype wireframe thingy.” For obvious reasons, however, I was encouraged to change the name by pretty much everyone I know. I liked the specificity of the name, but brevity won out. So, I settled on: Priority Guide.
Essentially, with the priority guide, we create a single deliverable that provides direction for content-focused design and mobile-first development in something resembling a wireframe.
By nature, a mobile-sized approach is narrow and forces more of a single column layout. The single column, in turn, causes a linear display of content and features. This linear display makes priority and hierarchy much more apparent than a desktop-sized wireframe, especially if you attempt to use a draft of real content instead of greek text—hence the content prototype.
At that point, armed with just this priority guide, the designer sets off to create something beautiful. The designer cranks up trusty ol’ Photoshop and begins a new layout at a traditional desktop resolution—just like you may have done for the past ten years. For a good web designer (outfitted with his super-duper powers of visualization), it is a snap to make design decisions for a desktop resolution while looking at a mobile plan. That’s just how their minds work.
Download a hi-res JPG of the final design.Once the design work is done, the handoff to the developer consists of the completed desktop-sized design and the original mobile-sized wireframe.
Don’t Let the Simplicity Fool You
This approach may sound simple—which is part of the beauty of it—, but it also provides some real benefits:
- The developer is provided a sort of bookended direction, both desktop and mobile. Two guides to follow, each offering unique information. Some interpretation still has to be made, which isn’t a bad thing, but there is far less guess work.
- The designer is given a wireframe that provides hierarchy but does not dictate desktop-sized layout, where ample real estate allows for more creative room to breathe—designers need to be given their freedom, lest they shrivel up into sad, hollow, hipster-jean-wearing shells of themselves.
- From the prototype and their linear approach, hierarchy can be understood fairly quickly, and the foundation for mobile-first markup and style is implied but flexible.
- All of this is done in a two-deliverable process, like before, so it saves time and budget. Any method you get better results in the same amount of time (or less) is a good.
A Note About Context
Any conversation concerning mobile web draws questions of context. Is there a “mobile context”? If one does exist, do users actually have different expectations of a website’s content while they are mobile? And, if users do have different expectations, how do we address them? Whew.
In short, those questions aren’t what this article is about. These issues are being discussed in depth elsewhere. I believe that questions of context can be answered very differently, depending on the project. I’ll leave it to you and your team to apply due diligence in addressing context.
What I will suggest, however, is that you tread very carefully when making assumptions about your users and limiting content as a result. Though a mobile context may exist, you can’t make those assumptions based on screen size alone. People surf the web on their phones from their couches, and they have all the time—and expectation—to access all of your site’s content as they sit and watch TV. This is why we believe in a responsive web design approach that acts as a safety net where little to no content is abridged from the experience of the user. This is the approach reflected in the above article—plan for all content in all contexts.
Tools To Consider
Style Tiles
Designer Samantha Warren just recently presented her concept of Style Tiles at SXSW. She was featured just days later on A List Apart discussing the same concept. We love it. It’s one of those concepts that makes you slap your forehead, wondering why you didn’t think of it sooner. It makes sense for web design in general, even more so in responsive design where client delieverables are much more tricky. We are already planning to integrate this into our workflow. We envision this deliverable being presented to a client during the wireframing process, so progress concerning style and layout can be made separately but concurrently.
Keynote for Wireframes
I’ve been loving Keynote for wireframes lately—it’s even great for mobile-sized content prototype wireframe thingies. If you haven’t tried it, give it a shot. It’s quick, easy to learn, and easy to share. A really interesting article was written recently about designing in Keynote. I’m not sure I’m ready to go that far. However, it’s a fantastic wireframing and planning tool, and there are some great kits to get you started. We’ve been using this one from Travis Isaacs.
Conclusion
If you gain nothing more from this article, let me remind you what you already know: don’t be afraid to try new things. No process is a silver bullet—the same is true of tools and deliverables. If the ideas above don’t fit your project, scrap them and try others. However, you must evolve your design process to account for the evolution of the web and users. If you hope to solve new problems, you’re going to need a new approach.
You must also address the very human issue of communication. Earlier and more frequent collaboration among team members and the client must become the rule in your workflow, not the exception. Content, design, and development team members must review and collaborate regularly at every stage in the creation process until the site is live. We can’t ‘throw it over the wall’ anymore—at least, not if we want our sites to be excellent. There are simply too many moving parts now. Go forth and collaborate.
(jc) (fi)
© Drew Clemens for Smashing Magazine, 2012.
-
from BittBox
Within any field of application production you often find the workload split between design and development. It’s a simpler process to let the designer handle creating the user interface while the developer codes it into reality. This is the case for desktop applications, mobile apps, and especially websites.
In this article I want to share a few ideas for how web designers and developers can work together with each other in harmony. It can be a struggle to keep everyone on the same page. Especially when you’re sharing documents and graphics between a group of 4+ web professionals. It’s super important that the team is willing to compromise and work together in problem solving. But as always, these ideas are much easier to understand than apply into real-life situations.
Outlining the Project
Before even starting on a project it’s a good idea to round up your team and have a quick planning session. Whether it’s just you and a partner or a studio of 5 or more employees – a solid plan is almost essential. Everyone should feel comfortable sharing their ideas and offering feedback on the project at large.
Often times the webpage design and user interface will need to be the first priority. Without a full design, developers cannot do much work aside from coding the “bare-bones” skeleton for a web app. During this initial planning session have the designer(s) taking notes for references. Everybody should eventually commit to a single idea and push forward with it vigorously.
It’s also true that the development process should take longer than just designing a mockup. Even on a team of 3 or 4 developers it will require days(or even weeks) of coding. This is because a website is built on the frontend HTML/CSS/jQuery along with a possible backend system through any number of programming languages. The best way to ensure each of these processes goes smoothly is to get everybody thinking on the same terms early-on.
Communication is Key
More than anything else you need to have strong communication skills within your staff. If the team cannot express their ideas properly then there is little hope for the project to be successful. Developers can often keep up with sharing ideas on the frontend design – this just includes logos, gradients, patterns, menus, and other important interface elements.
However designers are trained to think in terms of colors and usability. They may not fully understand the inner-mechanisms for how a web application will function. If you happen to land a designer who also understands frontend coding this is exceptionally lucky! Web designers who can also lend a hand in the frontend code are more integrated into the development scene.
This will dramatically cut down on the time and pace of your each project. Of course, this shouldn’t be expected as the “typical” scenario considering it does take a bit of real studying to understand these languages. But your communication skills will go a lot further – especially during the initial design stages in preparing a mockup layout.
The communication between developers is just as equally important. If you have a team of devs who cannot explain their code to each other then things will fall apart very quickly. I like to setup a project workspace where everybody can collaborate online together. It provides a digital meeting place to share ideas and log who has completed which tasks on which days.
Revise, Revise, Revise!
Part of the process when building a website is going back and making changes where they are needed. Revisions are essential during the design process and even developers may change their mind mid-way into the project. It’s important to not get discouraged and always keep your spirits high.
There is nothing wrong with changing some areas of the layout after the initial draft. Things can be looking great one day and feel very awkward on the next. Don’t be afraid to take that leap of faith and change things up! Of course, it’s important to have everybody in agreement before handling these changes. But afterwards the team should feel a lot better and be moving towards the next set of goals.
Keep Designers Engaged
There is also the false idea that once your designer has provided the mockups they are dismissed from much of the project’s development cycle. This couldn’t be further from the truth. In actuality you should strive to include them in other areas of testing, web performance, and user experience.
Web designers are not all too ignorant of how a website runs and operates. Honestly they probably got into designing for the Internet because they have an interest in websites(go figure). Use this to your team’s advantage and have designers helping out in smaller aspects of the project. Aside from revisions there are plenty of tasks you can assign to your web designer:
- Building Website SEO & keywords
- Validating for proper HTML5/CSS3 code
- Checking the layout in all supported web browsers
- Handling graphics for marketing(banner ads, avatars, forum signatures)
This certainly isn’t an exhaustive list and there are plenty of other ideas to consider. The point is to keep everybody working on something until the project is totally done and ready to be put up live. Whether you’re building a website for clients or a project of your own ideas shouldn’t matter in the slightest.
Conclusion
Web designers and developers are adjusted to performing two very distinct tasks. Yet without each other there would be no way for any modern website to exist. There are plenty of developers who work on their own and manage with free PSDs and their own simplistic layouts. And similarly there are lots of designers who can get by with a minuscule understanding of HTML/CSS to build up their layouts into reality.
Yet when you can have a team of individuals focusing on what they know best you begin to see powerful results. This is how some of the greatest websites in the world have been constructed! Keep the positive energies flowing and make sure everybody is on board with each step in the process. Along with the ideas presented above let us know your thoughts or suggestions in the post discussion area.
-
from Jon Acuff’s Blog
(As I wrote recently, I’m going to end the year with the top 5 posts from 2011. Today kicks off with number #5. See you on Sunday, January 1 for Finish Year!)
A few weeks ago, I was supposed to run in an event called “The Warrior Dash.” It’s a 5K obstacle course that involves mud, fire, water and Viking helmets. I’d signed up for it months ago. But 24 hours before the event, I decided not to go.
Why?
Because I’m trying to disappoint the right people in my life.
For years, I thought, if I lived a perfect life, I could make everyone happy and never disappoint anyone. I know that’s a foolish thought, but people-pleasers like me are constantly intoxicated with thoughts like that.
But the day before the race I realized something: I was going to be out of town for the next three weekends. I speak at the Dave Ramsey Live Events and we were headed out to visit three different cities.
I had a choice to make.
I could either disappoint my kids and tell them, “Hey, on the Saturday before I’m gone for three Saturdays in a row, I’m going to spend five hours running in a race instead of hanging out with you.”
Or
I could disappoint my friends and tell them, “I’ve got to bail on the Warrior Dash.”
I decided to disappoint my friends. And the funny thing is that three of them had already decided not to run the race for the same reason. We hadn’t trained together for it, running over fire or through mud in the weeks before, and we weren’t that invested in it.
So instead of doing the race, I spent the entire Saturday with my wife and kids at a botanical garden. It was an amazing day, and I felt instantly like I had made the right decision.
In your life, you’re going to disappoint people, people who want your time or your input or your attendance. And often you won’t be able to give it to them. But it’s okay to disappoint people, as long as you make sure you’re disappointing the right people.
The biggest lesson for me was to not say “yes” to things I am ultimately going to say “no” to. When my friends asked me to run in the race, I should have looked at my calendar, seen the travel I had scheduled for this fall, and said “no.” But I didn’t want to disappoint them, so I agreed to it. Which only amplified the disappointment of me eventually saying no 24 hours before the race.
Don’t tell polite lies, like “Let’s grab coffee sometime” when you have no intention of doing that.
Don’t believe the internal lie that you have to say “yes” to everything and will never disappoint anyone.
You will disappoint people. That’s going to happen. There’s great freedom in realizing that.
Just make sure when you have to disappoint someone, you disappoint the right people.
Question:
Have you ever struggled with saying “no” to someone? -
from Lifehacker
Android: Just a couple of days ago, the latest version of Dropbox for Android showed up as a preview build. Now it’s here officially and you can grab it from the Android Market. More » -
from Lifehacker
iOS: Pulse, one of our favorite iOS newsreaders, just went through a beefy update that brings a new, stylish interface, and a new recommendation feature that gives you new feeds you might like. More » -
from Lifehacker
From the “silly but useful” files: YouTube comedians Joe and Buzz explain how to remember that thing you always forget—whether it be turning off the stove, locking your apartment door, or feeding the cat. Just sing yourself a little song after you perform the action in question. More »
