    
|
|
|
From puka shell necklaces to planking, the power of trends is undeniable. In a digital age dominated by social media, memes, and an audience with an ever-shortening attention span, trends have become a part of Internet life.
And as the Web continues to adolesce, web design is subjected to rapidly changing trends as well.
Continuously developing design and development technologies mean that trends in our industry quickly come and go.
I’ll discuss some of the worst web design trends we have seen throughout the Internet’s history, many of which are — thankfully — not that common anymore.
We’ve all seen a site that loads with sliding photography, illuminating status bars, and a cacophony of visual excess. The thought behind a splash page is "Watch this long ‘short intro’ video to discover how wickedly-awesome our website is!"
Hoping for a strong first impression, sites that adopt this practice of showing a splash page definitely make an impact. Unfortunately, it’s usually an overly negative one.
Splash pages waste time and delay people from accessing the content of the website. Site users just flock to the "click to skip" link, or, in some cases, can’t even find it and decide to bounce instead of waiting.
Conclusion: A good homepage, information architecture and content strategy are all you need. Don’t waste precious time by showing users pointless filler content.
Rounded corners, reflections, drop shadows and gradients say one thing: 2005.
As the Web moves toward a flatter, harder-edged aesthetic, don’t let your site get stuck with an outdated look.
These days, dimensionality and drop-shadowing look soft and tentative. Skeuomorphism for skeuomorphism’s sake doesn’t really accomplish anything, other than potentially confusing your viewer with an overcomplicated design.
You can do better. Simplify your designs to make your interfaces more user-friendly and to improve UX.
Conclusion: Though some argue that flat is not the right direction, with major tech companies like Apple, Microsoft, Google and others going flat, the reality is that this is what Web users will come to expect.
Good stock photos don’t actually look like a stock photo, but they can be astronomically expensive.
So, instead, we’re often shown cold, lifeless photos of people who are smiling on the outside, but crying on the inside.
(Visit Awkward Stock Photos if you’d like to explore to dark, twisted world of stock photography.)
Conclusion: If photos are needed on your site, try and produce them yourself. If this is not an option, be selective with your stock photography. Use a critical eye to determine if adding the photo is actually going to improve the look of your site or make it look like a joke.
In the mid-2000s, the average Web-savvy user was defined by the amount of personalization on their MySpace profile.
Some designers picked up on this trend, over-designing their sites to the point of complete chaos, whether the site was designed by a team of 10 different people, or 1 eager-beaver designer wanting to prove their worth by adding every kind of design element/texture/animation/etc. into one page.
Source: theworldsworstwebsiteever.com
Conclusion: Just because you can, doesn’t mean you should. Less is more.
The strength of Flash is also its weakness. Though animations and movement enhance the look of your site and definitely get attention, they are also incompatible with many Web devices (such as those that use, ahem, iOS).
What good is a large amount of visually-stimulating content if many of your users can’t even see it?
Who doesn’t hate seeing web pages like this?:
With the maturation of CSS3 transitions and HTML5 standards, we can create impressive animated sites without the use of proprietary, closed-source software.
Even the company that owns Flash agrees that it’s an outdated technology and that HTML5/CSS3 is the future.
If you’re still in the Flash bandwagon and are wanting to jump off, these posts might inspire you to take the plunge:
Conclusion: It’s time to stop relying on Flash and get on board HTML5, CSS3 and JavaScript which accomplish many of the same things as Flash with less compatibility and performance issues.
Some web designers want to engage their viewers’ senses, so they add some tunes to help build a connection.
If you’re considering this, keep in mind two things: 1) some of your viewers have their sound muted and will thus miss out on your awesome jams, and 2) those that do have the sound on are likely listening to something else or looking to hear something specific.
Not to mention the potential issues with site loading speed, licensing, user experience, etc.
Conclusion: Unless you’re a DJ company or a radio station, skip the music.
We’ve all experienced the frustration of loading a webpage and immediately being bombarded with a gazillion un-closable pop-up windows. It truly harms our experience on the site and makes us wary of coming back.
Unfortunately, today, popup windows are being reincarnated in the form of modal window overlays that open automatically and interrupt our reading experience. Check out Tab Closed; Didn’t Read to see a showcase of disruptive window overlays.
Source: tabcloseddidntread.com
Conclusion: Ads are a part of life, and they’re an important way for many sites to generate revenue. That being said, no one likes an ad that’s overly disruptive.
Like any trend, what’s popular in web design comes and goes with the times. If you have a robust development and design team, incorporating current trends can make your site look fresh and relevant.
Just remember that trends have a shelf-life, and be prepared when it’s time to make a change. What’s hot right now could soon go the way of sparkly mouse pointers and site visitor counters.
For those who are more risk-averse (or strapped for time), it’s best to focus on more evergreen design ideas that will always look professional and be effective.
[Some images courtesy of Picjumbo.]
Rick Debus is the founder and CEO of Signazon.com, a national e-commerce printing company based in Dallas, Texas. With over 15 years of web design and development experience, he’s passionate about bringing unique and innovative solutions to the Internet. Connect with him on Google+.
The post Terrible Web Design Trends appeared first on Six Revisions.
]]>
 |
After recently writing an article on “Writing A Better JavaScript Library For The DOM”, I realized that the topic is indeed a very complex one and that it’s important to understand what exactly live extensions are and how they work. In today’s article, I will answer most questions that were asked regarding “live extensions” and help you get going with this new concept.
Event handling is one of the key principles of working with the DOM. Events are the primary means of receiving feedback from user interaction.
In this first example, documentation and tutorials that cover DOM events is what I call “simple event binding”. You attach a listener for the desired event on the DOM element in which you expect it to happen on.
link.addEventListener("click", function(e) {
// do something when the link is clicked
}, false);
The first argument indicates the type of an event, the second argument is a listener, and the third argument defines an event phase (so-called “bubbling” or “capturing”). The reason why the last argument exists is because most DOM events traverse the DOM tree from document node to target node (capture phase) and back to the document node (bubble phase). This process is called “event flow” and brings several powerful features.
Instead of attaching a handler for each element in a group, we can attach one listener onto an ancestor shared by all of the elements in that specific group. Then, we can determine where an event took place using the target property of the event object, passed into the listener. This is known as “event delegation”:
list.addEventListener("click", function(e) {
if (e.target.tagName === "LI") {
// do something when a child <li> element is clicked
}
}, false);
By having all event handlers on a particular parent, we can update the innerHTML property of this element without losing the ability to listen to events for new elements. The feature was called “Live Events” in jQuery, and it quickly became popular because of its ability to filter events by a CSS selector. Later, delegated events replaced them due to their flexibility by allowing to bind a listener to any element within the document tree.
But even event delegation does not overcome the following problems:
scroll or mousemove,load, error, etc.This is what live Extensions aim to solve.
Take a look at the following diagram that explains the responsibilities:
1. DOM Mutations For Existing And Future Elements
Imagine you want to develop a reusable datepicker widget. In HTML5, there is a standards-based <input type="date"> element that could be used to create a polyfill. But the problem is that this element looks and behaves very different from browser to browser:
Date input element in different browsers.
The only way to make the element behave consistently is to set the type attribute value to "text". This will cancel a legacy implementation and enable JavaScript to make your own. Try defining a live extension with the example below:
DOM.extend("input[type=date]", {
constructor: function() {
// cancel browser-specific implementation
this.set("type", "text");
// make your own styleable datepicker,
// attach additional event handlers etc.
}
});
2. Media Query Callbacks
I highly recommend reading Paul Hayes’ article on how to “Use CSS transitions to link Media Queries and JavaScript”.
“A common problem in responsive design is the linking of CSS3’s media queries and JavaScript. For instance on a larger screen we can restyle, but it might be useful to use JavaScript and pull in different content at the same time, e.g. higher quality images.”
Paul was probably the first who started to use “hidden force” of CSS3 animation events to solve mutation-related problems. Live extensions are powered by the same trick, therefore you can use them to make DOM modifications depending on the current viewport:
DOM.extend(".rwd-menu", {
constructor: function() {
var viewportWidth = DOM.find("html").get("clientWidth");
if (viewportWidth < 768) {
// hide <ul> and construct Emmet abbreviation for a
// <select> element that should be used on small screens
this.hide().after("select>" +
this.children("li").reduce(function(memo, item) {
var text = item.get("textContent"),
href = item.find("a").get("href");
memo.push("option[data-url=" + href + "]>
{" + text + "}");
return memo;
}, []).join("^"));
// redirect to stored url when an <option> is selected
this.next().on("change", this.onMenuChanged.bind(this));
}
},
onMenuChanged: function(select) {
var selectedIndex = select.get("selectedIndex");
// redirect to the appropriate data-url attribute value
location.href = target.child(selectedIndex).data("url");
}
});
3. Element Media Queries
Back in 2011, Andy Hume implemented a script for applying styles depending on the dimensions of a particular element (not viewport, like for media queries). Later, this technique was named “element media queries”:
“Media queries work really well when you want to adjust the core layouts of the site, but they’re less suited to changing styles at a smaller more granular level.”
With the help of live extensions, it’s easy to implement element media queries support using the offset method:
DOM.extend(".signup-form", {
constructor: function() {
var currentWidth = this.offset().width;
// add extra class depending on current width
if (currentWidth < 150) {
this.addClass("small-signup-form");
} else if (currentWidth > 300) {
this.addClass("wide-signup-form");
}
}
});
4. Efficiently Attach A Global Listener To Frequent Events
DOM.extend(".detectable", {
constructor: function() {
// mousemove bubbles but it’s usually a very bad
// idea to listen to such event on a document level
// but live extensions help to solve the issue
this.on("mousemove", this.onMouseMove, ["pageX", "pageY"]);
},
onMouseMove: function(x, y) {
// just output current coordinates into console
console.log("mouse position: x=" + x + ", y=" + y);
}
});
5. Listing Non-Bubbling Events On A Document Level
DOM.extend("img.safe-img", {
constructor: function() {
// error event doesn’t bubble so it’s not
// possible to do the same using live events
this.on("error", this.onError);
},
onError: function() {
// show a predefined png if an image download fails
this.src = "/img/download-failed.png"
}
});
The problems which live extensions aim to solve is not entirely new, of course. There are different approaches that address the above-mentioned issues. Let’s have a quick look at some of them.
Internet Explorer started supporting DHTML behaviors with IE 5.5:
“DHTML behaviors are components that encapsulate specific functionality or behavior on a page. When applied to a standard HTML element on a page, a behavior enhances that element’s default behavior.”
To attach behavior to future elements, Internet Explorer used an *.htc file with a special syntax. Here’s an example illustrating how we used to make :hover work on elements instead of <a>:
<PUBLIC:COMPONENT URN="urn:msdn-microsoft-com:workshop" >
<PUBLIC:ATTACH EVENT="onmouseover" ONEVENT="Hilite()" />
<PUBLIC:ATTACH EVENT="onmouseout" ONEVENT="Restore()" />
<SCRIPT LANGUAGE="JScript">
var normalColor, normalSpacing;
function Hilite() {
normalColor = currentStyle.color;
normalSpacing= currentStyle.letterSpacing;
runtimeStyle.color = "red";
runtimeStyle.letterSpacing = 2;
}
function Restore() {
runtimeStyle.color = normalColor;
runtimeStyle.letterSpacing = normalSpacing;
}
</SCRIPT>
</PUBLIC:COMPONENT>
If you provided the above-mentioned code into the hilite.htc file, you could access it within CSS through the behavior property:
li {
behavior: url(hilite.htc);
}
I was really surprised to discover that HTML components supported creating custom tags (starting from version 5.5), have single domain limitations and tons of other stuff that you probably have never used before. Despite Microsoft submitting a proposal to W3C, other browser vendors decided not to support this feature. As a result, HTML components were removed from Internet Explorer 10.
In my previous article, I mentioned the Decorators which are a part of Web components. Here’s how you can implement the open/closed state indicator of the <details> element using decorators:
<decorator id="details-closed">
<script>
function clicked(event) {
event.target.setAttribute('open', 'open');
}
[{selector: '#summary', type: 'click', handler: clicked}];
</script>
<template>
<a id="summary">
▸ <content select="summary"></content>
</a>
</template>
</decorator>
<decorator id="details-open">
<script>
function clicked(event) {
event.target.removeAttribute('open');
}
[{selector: '#summary', type: 'click', handler: clicked}];
</script>
<template>
<a id="summary">
▾ <content select="summary"></content>
</a>
<content></content>
</template>
</decorator>
Decorators are also applied using the special decorator property in CSS:
details {
decorator: url(#details-closed);
}
details[open] {
decorator: url(#details-open);
}
You’ll quickly notice that this is very close to what Microsoft proposed in HTML Components. The difference is that instead of separate HTC files, decorators are HTML elements that can be defined within the same document. The example above is only provided to show that the Web platform is working on these topics, since decorators aren’t properly specified just yet.
While designing APIs for live extensions, I decided to follow the following rules:
As a result, there are only two methods to deal with: DOM.extend and DOM.mock.
DOM.extend declares a live extension. It accepts a CSS selector as the first argument which defines what elements you want to capture. General advice: try to make the selector simple.
Ideally, you should only use a tag name, class or attribute with or without a value or their combinations with each other. These selectors can be tested quicker without calling an expensive matchesSelector method.
The second argument is a live extension definition. All properties of the object will be mixed with an element wrapper interface except constructor and event handlers.
Let’s look at a simple example. Let’s assume we have such an element on a Web page:
<div class="signin-form modal-dlg">...</div>
The task is to show it as a modal dialog. This is how the live extension could look like:
DOM.extend(".modal-dlg", {
constructor: function() {
var backdrop = DOM.create("div.modal-dlg-backdrop");
// using bind to store reference to backdrop internally
this.showModal = this.showModal.bind(this, backdrop);
// we will define event handlers later
},
showModal: function(backdrop) {
this.show();
backdrop.show();
}
});
Now you can access the public method showModal in any (present or future) element that has the modal-dlg class (in our case this is the signin-form div):
var signinForm = DOM.find(".signin-form");
DOM.find(".signin-btn").on("click", function() {
// the signin button doesn’t have the modal-dlg class
// so it’s interface doesn’t contain the showModal method
console.log(this.showModal); // => undefined
signinForm.showModal(); // => shows the signin dialog
});
Note: The better-dom-legacy.js file which is included conditionally for Internet Explorer versions 8 and 9, contains the es5-shim library so you can safely use standards-based EcmaScript 5 functions (such as Function.prototype.bind) in your code. I’ve been using the bind method heavily in my code to build testable methods easily.
The constructor function is called when an element becomes visible. This is because of the animationstart event that is used to implement DOM.extend. Browsers are clever so they don’t fire animation events for hidden elements. This lazy initialization saves resources sometimes, but be careful with accessing initially hidden elements.
In older Internet Explorers versions such as 8 and 9, contentready event from better-dom-legacy.htc is used to implement live extensions. Therefore, the constructor function executes immediately in these browsers — even for hidden elements.
Note: Keep in mind not to rely on time whenever an extension has been initialized. The actual initialization of a live extension varies across browsers!
Constructor is usually the place where you attach event handlers and perform DOM mutations where necessary. Once the function has been completed, all methods that begin with “on” (in better-dom 1.7 also “do”) followed by an uppercase letter, event handlers will be removed from the element wrapper’s interface.
Let’s update our .signin-form live extension with the help of a close button and the ESC key:
DOM.extend(".modal-dlg", {
constructor: function() {
var backdrop = DOM.create("div.modal-dlg-backdrop"),
closeBtn = this.find(".close-btn");
this.showModal = this.showModal.bind(this, backdrop);
// handle click on the close button and ESC key
closeBtn.on("click", this.onClose.bind(this, backdrop));
DOM.on("keydown", this.onKeyDown.bind(this, closeBtn), ["which"])
},
showModal: function(backdrop) {
this.show();
backdrop.show();
},
onClose: function(backdrop) {
this.hide();
frame.hide();
},
onKeyDown: function(closeBtn, which) {
if (which === 27) {
// close dialog by triggering click event
closeBtn.fire("click");
}
}
});
Despite the fact that the live extension contains both onClose and onKeyDown methods, they won’t be mixed into the element wrapper interface:
var signinForm = DOM.find(".signin-form");
console.log(signinForm.onClose); // => undefined
console.log(signinForm.onKeyDown); // => undefined
This kind of behavior exists simply because you can have multiple live extensions for a single element that may overload public methods of each other and produce unexpected results. For event handlers, this is not possible; they exist only inside of the constructor function.
Sometimes it is useful to extend all of the element wrappers with a particular method (or methods). But then again, you can also use the universal selector to solve the problem:
DOM.extend("*", {
gesture: function(type, handler) {
// implement gestures support
}
});
…
DOM.find("body").gesture("swipe", function() {
// handle a swipe gesture on body
});
The * selector has a special behavior: all extension declaration properties will be injected directly into the element wrapper prototype except for the constructor which is totally ignored. Therefore, there is no performance penalty that is usually associated with the universal selector.
Note: Never pass more specific selectors such as .some-class * into DOM.extend because they are slow and do not have the same behavior as mentioned above.
More often that not, it makes sense to split a large live extension into several pieces to reduce complexity. For instance, you may have such an element on your page:
<div class="infinite-scroll chat"></div>
There are two different extensions attached to it. The .infinite-scroll extension implements a well-known infinite scroll pattern, e.g. it’s responsible for loading new content. At the same time, the .chat extension shows tooltips whenever a user hovers over a userpic, adds smileys into messages, and so on. However, be accurate with multiple extensions: even though all event handlers may have been removed from the interface, you still may have public methods that intersect with each other.
Live extensions respect declaration order; you can use this to your advantage and develop your own component hierarchy. Late binding helps to declare overridable event handlers and method overloading allows to redefine a method implementation in a child extension:
DOM.extend(".my-widget", {
constructor: function() {
this.on("click", "_handleClick");
},
showMessage: function() { }
});
DOM.extend(".my-button", {
_handleClick: function() {
console.log("I am a button!");
},
showMessage: function() {
alert("I am a button message!");
}
});
If you take a closer look at the code above, you’ll notice that the .my-button extension does not attach a click listener. The registration is done with the help of late binding instead of a simple event handler in .my-widget. Late binding is a perfect choice here: even if a child does not implement _handleClick there won’t be any errors since the handler will be silently ignored.
While spreading functionality across multiple modules is possible, this is not recommended in everyday use. Double check if you really need to go in this direction, because it’s the most complex one.
One requirement for a high-quality widget is test coverage. New elements are captured by a live extension asynchronously, so it’s not that easy to simply make them in memory. To solve this problem, better-dom has the DOM.mock function:
var myButton = DOM.mock("button.my-button");
DOM.mock creates elements, just like DOM.create. Additionally, it synchronously applies the registered live extensions to the newly created elements. For even more convenience, all wrapper objects created by DOM.mock preserve event handlers (e.g. onClick), so you can test them.
From time to time, you may need to create a “fake” instance of an element. Use DOM.mock without arguments to make such an object:
console.log(DOM.mock().length); // => 0
A test for the modal dialog live extension introduced earlier could look like this (I use Jasmine):
describe(".modal-dlg", function() {
var dlg, backdrop;
beforeEach(function() {
dlg = DOM.mock("div.modal-dlg");
backdrop = DOM.mock();
});
it("should hide itself and backdrop on close", function() {
var dlgSpy = spyOn(dlg, "hide"),
backdropSpy = spyOn(backdrop, "hide");
dlg.onClose(backdrop);
expect(dlgSpy).toHaveBeenCalled();
expect(backdropSpy).toHaveBeenCalled();
});
it("should show itself and backdrop on show", function() {
var dlgSpy = spyOn(dlg, "show"),
backdropSpy = spyOn(backdrop, "show");
dlg.showModal(backdrop);
expect(dlgSpy).toHaveBeenCalled();
expect(backdropSpy).toHaveBeenCalled();
});
});
There are some cases when filtering with a CSS selector is not flexible enough. For instance, let’s say you want to declare a live extension but only for browsers that support (or do not support) a particular feature. You may need to run tests in a headless browser like PhantomJS that support the feature natively. Starting with better-dom 1.7, DOM.extend supports the optional argument condition.
Assume we need to create a polyfill for the placeholder attribute. It doesn’t make sense to implement it for browsers that have built-in support. Below is an example of how the feature detection could look like:
var supportsPlaceholder = typeof DOM.create("input")
.get("placeholder") === "string";
By using just a simple “If” statement as shown in the example below, we won’t have an ability to test the widget because PhantomJS supports the placeholder attribute and the live extension will never be declared.
if (!supportsPlaceholder) {
DOM.extend("[placeholder]", {
// implement placeholder support
};
}
In order to solve this problem, you can use an extra condition argument in DOM.extend that might be Boolean or a function:
DOM.extend("[placeholder]", !supportsPlaceholder, {
constructor: function() { … },
onFocus: function() { … },
onBlur: function() { … }
});
DOM.mock ignores the condition argument, so you can access all methods of the [placeholder] extension even if current browser passes the check:
var input = DOM.mock("input[placeholder=test]");
typeof input.onFocus; // => "function"
Live extensions — and better-dom as an implementation of the concept — are a good base to build upon whenever your target is uncertain, e.g. when creating a polyfill that may or may not be used on a particular site. Or regular widgets that may or may not be needed, depending upon some AJAX call.
Live extensions aim to separate declaration and the use of widgets. They bring loose coupling (or decoupling, rather) of any DOM-based component, and allow your code to become smaller, cleaner and easier to maintain. You can even combine such independent pieces with any existing framework within the market (or with the vanilla DOM, of course).
You may now be thinking, “But wait, there are projects like Polymer or x-tags, right?” Well, live extensions cover a different area; they are not about custom tags but rather about extending existing ones instead. I prefer a standards-based way (if possible) of creating UI widgets, so making polyfills is my choice.
Better-dom also has another advantage: a carefully crafted live extension does not force you to rewrite a website’s markup using different tags. All you need is to simply include a script file on your page. Standards-based elements can potentially work without JavaScript, so they degrade well when it’s disabled. And the library’s browser support allows you to start using live extensions straight away.
Feel free to share your thoughts in the comments section below or on the better-dom project home page.
(il)
© Maksim Chemerisuk for Smashing Magazine, 2014.
]]>
Despite the fact that it’s a huge trend these days, using large scale photographs, or just photography incorporated into your design at all, can be tricky to get right.
If you’re struggling to get it right, you could do worse than read How To Use Photography in Web Design, a post from the archives that walks you through ways to pull this off. But when you decide to go all out and build your entire background using a photograph the ante has officially been raised, and you have to take even more care to ensure you do it well.
So we went out and scoured the web to find enough fine examples to build a showcase of websites that successfully use images as their backgrounds to help get your inspiration fuelled and firing on all cylinders. Scroll on down through the collection and see how this stylish and often daring design choice can pay off when effectively crafted.
Herzschmerz 2.0 does a great job of using a number of large images throughout the site all the while maintaining a clean minimalist look.
Jens Lehmann uses a large photo of himself as his background giving the site a level of personalization. Users can get a sense of who he is.
Whatsmynvme uses a large gridded image not only as the background, but they make each piece of the grid into a different link in their portfolio. Clever execution of the concept overall.
Pauline Osmont uses beautiful, clean background images with creative use of typography and geometry layered on top of them to create a clean but very visually stimulating site.
The Dangers of Drug Driving site uses large background images through the dashboard of a car to convey what it’s like driving on various controlled substances. Very tongue-in-cheeky and playful in their delivery.
Humblebee uses large, strong imagery fully filling the background of the site with small bits of minimalist typography for a clean bold look that just works.
Hotel Universo Lucca makes use of large, full color background images to show off the beauty of their establishment. Keeping the brand at the forefront of the site.
Gyga Voyages uses this same technique to show off the gorgeous places you can visit around the world via their specialized travel services. Working from the mission that a good journey is a work of art, their site sells this idea with perfect tone and style.
Vilebrequin Magazine uses its entire front page as its main menu, using a different background image for each link. The large, beautiful imagery continues throughout the site keeping you engaged in its message.
Prime & Fire uses multiple large scale images as backdrops for the site’s mission and presentation of their content. Instilling the design with a sense of dynamic creativity, and winning users over instantly.
J Taylor Design uses a large background image to highlight their cause by showcasing their hoodies for charity and directing users to where they can be printed.
Vita Frute Cocktails uses big vibrant images of tropical locations as you scroll through the site. You can almost taste the cocktails via their picturesque pulling at your imagination!
Customedia takes a slightly different route by using a heavily blurred image as their background with clean, elegant typography on top creating a unique yet pleasing experience.
Bellezza use amazingly wild and stylish background images that perfectly conveys their unique and wild style to the user with all the boldness and flair you would expect from this brand.
Pavel Huza‘s use of a muted, monochrome pink background offers a very calm and friendly feel for this site. Welcoming the user in with a warm and soft feel to the design.
Platinum PR uses bright, fun and quirky images with big bold typography layered over the top. Perfectly representing their unique style and playful nautre.
Telegraph Creative uses a simple photograph of a clear sky above thick clouds. Couple this with the clean title and menu, not to mention the abundant white space, and this design denotes clear and open communication with ease.
House: Kampania uses large background images along with video that when combined create a site that captures the user’s attention making them want to go on an adventure.
Evolution Bureau uses a huge panoramic image as its background that you can scroll through a full 360 degrees. Really taking this idea of using large image backgrounds and evolving it. Pun intended, but it fits.
iveo uses a large image background to sell the idea that their web agency can really take your web presence to new heights. The hot air balloons could also make some see that they are full of hot air as the old saying goes, but hopefully those are not the dots that get connected.
This technique is not always the easiest to make work. With too busy an image, or one that doesn’t connect with the users, the entire concept you are trying to create can fall apart. Hopefully these examples have helped inspire you with some ways to pull this off with ease.
Have you used large images in the background of a site? Which of these designs works best for you? Let us know in the comments.
| Motivational Poster Bundle for the Office – only $27! |  |
|
|
It becomes obvious to any new immigrant that schools in the U.S. generally operate on a Christian calendar.
Winter break – Christmas, Spring Break – Easter.
Besides Yom Kippur and Rosh Hashanah, kids rarely get off for holidays associated with other faiths.
Many New Yorkers want to change that, and it seems Mayor Bill de Blasio may be willing to oblige.
There is now a strong movement to make the Lunar (Chinese) New Year a school holiday. With the Asian population in NYC at 12.7%, a considerable number of absences occur annually (when the holiday falls on a school day). The Wall Street Journal reported an 80% absence rate in some schools. WNYC analyzed last Friday’s absentee rates.
Eid at-Fitr and Eid al-Adha are Muslim holy days that also draw large numbers of students from class. The mayor stated his intent to set aside these days, along with the Lunar New Year, as school holidays on the “Brian Lehrer Show” Monday.
He did not include Diwali, the Hindu festival of lights, which upset some communities.
Students can always get their absence approved for religious reasons. Still, some parents are faced with the quandary of either sending their children to school or observing tradition/religion.
A holiday hasn’t been added since MLK Day and according to Queens City Councilman Daniel Dromm:
“there is some flexibility within the existing calendar to add those additional days,”
Considering New York’s multi ethnic makeup, the introduction of these school holidays might make sense… but then… what about other holidays like Dewali? Will this start a trend elsewhere in the country? School kids everywhere sure hope so…
]]>
Measles! Whooping Cough! Polio! Sound like diseases of the past? Think again.
The Council on Foreign Relations created an interactive map to demonstrate the comeback of many preventable diseases. The United States has especially seen a resurgence of whooping cough that is making public health specialists scratch their heads.
Here is a statistic to put that into perspective…
Whooping cough affected less than 2,000 people in the early 1980s. In 2013, the prevalence was 24,000 cases, down from 50,000 in 2012.
Despite these re-emerging preventable diseases, many parents still refuse to get their children vaccinated. For some it is religious reasons, some babies can’t get vaccinated because of medical procedures, others fear vaccines cause autism but don’t worry, that was proven false.
In lower-income countries, the question isn’t whether to get vaccinated or not, it is lack of access. In Pakistan, polio epidemics are a public health threat because the Taliban has stopped humanitarian workers providing vaccinations accusing them of being spies.
Regardless of the reason for lack of vaccinations, all regions of the world are experiencing devastating consequences.
It’s true, no one likes getting shots, but we here at USDemocrazy can guarantee they are a lot better than the symptoms of whooping cough.
]]>
If you’re like us, and most Americans, you watched or at least attempted to watch the Super Bowl blowout last Sunday. If you are not a Seahawks fan, nor even a football fan, you may have watched the Super Bowl because of the one-of-a-kind commercials.
This year, one ad has been singled out for particular praise and scorn.
The Coca-Cola commercial is called “It’s Beautiful” featuring the song “America the Beautiful” sang in multiple languages. It had scenes celebrating Americans of different racial and ethnic backgrounds and even included a same sex couple (a first in the history of Super Bowl commercials).
The ad sparked the Twitter hash tag “#SpeakAmerican”, with many arguing that languages other than English should not be used to advertise products, because English is the de facto language of the United States.
Others were unhappy with the use of multiple languages to make a commercial appeal to racial minorities. They suggested the strategy was reminiscent of RJ Reynold’s targeted advertisements of menthol cigarettes to African-Americans.
So what’s your take on the commercial? Hit or miss?
]]>W3C introduced new input types to support working with month and year in HTML5. This article explores how to use this input type in your HTML5 web pages.
]]>|
|
|
|