Shareworthy articles and content syndicated from other sites. These aren’t things I’ve written or necessarily endorse, for the record.
Open source solutions are gaining popularity across a wide spectrum of businesses — but its adoption is slow in some sectors. Jack Wallen lists the industries he thinks should be using (or using more) open source software.
The days of standing in line waiting to pay for your Friday night video at Blockbuster are over. That’s right, the video rental company has filed for Bankruptcy last summer and has now put itself up for sale for the embarrassing starting price of $290 million.
A new infographic from Online MBA Programs shares some interesting stats in favor of the idea that Netflix played a major hand in the downfall of Blockbuster.
Before we get to the infographic, lets flash back to August, when Blockbuster declared bankruptcy and I asked, “Did web video bankrupt Blockbuster?” Back then, a little over half a year ago, a company spokesperson said, “We have every reason to believe we will come out of the recapitalization process financially stronger and more competitively positioned for the future.” It doesn’t look like things have gone according to plan. Although Blockbuster began a rentals-by-mail and streaming service belatedly in order to fight against competitors like Netflix, they didn’t come on strong enough or soon enough. It was a battle between old technology and new technology, and it looks like new technology won out in the end.
I should point out that Netflix didn’t take down Blockbuster single-handedly. I think that similar streaming services like Hulu Plus had something to do with it as well. That being said, Netflix is definitely the most successful of these Blockbuster-replacement services and has been steadily gaining traction over the years. They started out as a DVD rentals-by-mail service and business has been booming ever since they introduced a streaming subscription service as well. Blockbuster isn’t the only one feeling threatened by Netflix. Paid television services are also losing subscribers to the cheaper streaming site. HBO is holding out on providing Netflix with content because of the implications it would have for HBO’s subscriber base.
One of the most interesting stats on the infographic (which we’ll get to in a moment, promise!) is the fact that, “Back in 2000, Blockbuster declined several offers to purchase Netflix for a mere $50 million.” The offer was definitely not to shabby for a company that was, at the time, bringing in billions of dollars in revenue. Blockbuster is certainly hitting themselves for not jumping at the offer, which may have seemed irrelevant and unimportant at the time. In other interesting facts, did you know that the number of Netflix subscribers in the United States and Canada is equal to the population of Australia?!
Check out the info graphic on ‘How Netflix Destroyed Blockbuster’ below, and let us know what you think. Is Netflix the future of entertainment? Will they take down any other businesses on their rise to the top?
This post originally appeared at Social Times.
Join the conversation about this story »
This post is a continuation of our series, “Considerations for Mobile Design“. You can read Part 1: Speed, here.
How are our layouts affected by the (usually) small screen sizes of mobile devices? How do we serve mobile layouts to specific devices?
One of the first choices a designer makes when creating a website is determining its appropriate dimensions. At a time when desktop resolutions range anywhere from 1024x768px to 2560x1600px, designers are well accustomed to designing for the lowest common denominator. It’s not exactly good practice to create a layout at 1200px wide when 20% of your users are browsing on a 1024×768 resolution.
In the desktop world, the rate at which this minimum acceptable resolution changes is relatively slow. In one way, this is quite useful for web designers. If users are slow to upgrade their equipment, then our designs don’t have to struggle to keep up with them. Based on statistics from w3schools.com, beginning in the year 2000, it took 9 years for less than 10% of their viewers to be browsing at 800x600px. Similar statistics from w3counter.com show that between May of 2007 and January of 2011, the number of users browsing at 1024x768px has only dropped from 50.97% to 20.59%. Despite a 30% drop, it is still the most popular resolution based on their statistics.
While neither of these two polls are conclusive (they don’t measure an actual average of all internet users), they do effectively demonstrate how slow users are to adopt higher screen resolutions. This slow change has allowed for entire frameworks to be built for creating layouts based on a common low resolution.
Of course, fluid layouts have allowed designers to serve fine-tuned browsing experiences at different resolutions. When designing at percentages instead of pixels, it’s possible to make more use of physical screen space depending on resolution. A site with a max width of 90% will make use of 21.6 inches of a 24 inch monitor, while a fixed layout at 960px might only make use of 10 inches of the monitor. Fluid layouts can have drawbacks though (Does anyone else have trouble reading Wikipedia on a 1920×1200 display?). Even in using fluid layouts, there are limitations we have to consider such as the ideal number of words per line.
Saying that resolutions and display dimensions change rapidly in the mobile device market would be an understatement. The lifespan of mobile devices tends to be much shorter than that of a desktop (for instance, the average life of a cell phone tends to be around 18 months according to the United States Environment Protection Agency). Shorter device life spans in addition to constant new releases of mobile devices equate to an always changing landscape of popular resolution choices.
While this list won’t likely be relevant for very long, here is a list of popular resolutions on mobile devices as of February 2011:
| Resolution | Devices |
| 320×240 |
|
| 320×480 |
|
| 480×360 | Blackberry Devices: Torch, Storm, Bold |
| 360×640 | Symbian OS Devices: Nokia N8, Nokia C6-01, others |
| 480×800 |
|
| 768×1024 | iPad |
| 640×960 | iPhone 4 |
| 1280×800 |
|
|
Please note that this is a very limited list, and is by no means complete. What is important to take from this data is that a wide range of screen resolutions are out there, and new devices are introduced constantly. |
|
This wide variety in display size makes it difficult to decide how to choose an appropriate layout size for mobile devices. Should we target the lowest common resolution in handheld devices like we do on desktops? How does that scale onto newer tablets that offer 2-3x the resolution of a 320x240px smartphone display?
One possible solution is to create fluid layouts for mobile devices. Unlike desktop displays where building layouts that are too wide is a concern, handheld devices read much like a book or magazine. Full width layouts have worked for centuries for magazines and books—it seems likely that they should also work on a new generation of mobile devices.
Another possible solution is to create layouts for specific devices, and collections of devices. What does this mean? Instead of creating a one-size-fits-all layout, create a layout that changes depending on the current resolution and orientation of a device.
In the past, this was easier said than done. The only effective way to deliver a resolution-specific experience to a mobile device was either with javascript, or by detecting the user agent.
There was one other way to target handheld devices, but its implementation was a bit spotty across devices. You see, cascading stylesheets have the ability to target specific media types like screen, print, and even handheld. However, mobile browsers have implemented this feature is a variety of ways. Some mobile browsers will only load stylesheets targetting handheld media. Other mobile browsers will ignore handheld targeted stylesheets, and only read screen media stylesheets.
A big reason for the different implementation of this feature in mobile browsers is the “One Web” approach to web design:
…One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues, and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts…
Devices like the iPhone (and others) have largely ignored handheld media rules, because the creators felt that their device was capable of sufficiently displaying websites built for desktops. This essentially made the handheld media type useless for building specific layouts for many mobile devices.
With the introduction of CSS3 Media queries, it is possible to target devices through many other variables including device width, device orientation, and aspect ratio. Using Media queries, it’s possible to load specific styles on specific devices (or collections of devices). This is what Ethan Marcotte refers to as responsive web design.
Using CSS Media queries is simple enough. A standard implementation might look something like this:
<!-- All common styles --> <link rel="stylesheet" href="common.css" type="text/css" media="screen" /> <!-- Devices between 480-1024px --> <link rel="stylesheet" href="styles_max_1024.css" type="text/css" media="only screen and (min-width:481px) and (max-width:1024px)" /> <!-- Devices below 480px --> <link rel="stylesheet" href="styles_max_480.css" type="text/css" media="only screen and (max-width:480px)" />
The above code would load 3 stylesheets: styles for all devices, styles for devices in the 481-1024px range, and styles for resolutions 480px and below.
A drawback to this implementation is that 3 stylesheets means 3 separate http requests. To improve the speed at which our sites load, we want as few http requests as possible. This is especially important on mobile devices where download speeds and latency are usually worse than on desktops (see Considerations for Mobile Design (Part 1): Speed).
A different way to implement this same set of Media queries would be to use them directly in a single stylesheet. This could look something like this:
/* Common CSS Goes Here */
/* Devices between 480-1024px */
@media screen and (min-width:481px) and (max-width:1024px) {
/* styles go here */
}
/* Devices 480px & below */
@media screen and (max-width:480px) {
/* styles go here */
}
If it’s important to deliver a very specific design to a very specific device (ie: a web application built specifically for the iPad), you can use Media queries to deliver styles to exact resolutions:
<!-- iPad specific styles --> <link rel="stylesheet" href="iPad.css" type="text/css" media="only screen and (max-device-width:1024px) and (min-device-width:768px)" />
If the experience would benefit from different styles depending on a device’s current orientation, there is a way to handle that as well:
<!-- Orientation styles for devices w/ max width of 1024px --> <link rel="stylesheet" href="portrait.css" type="text/css" media="only screen and (max-device-width:1024px) and (orientation:portrait)" /> <link rel="stylesheet" href="landscape.css" type="text/css" media="only screen and (max-device-width:1024px) and (orientation:landscape)" />
Unless it’s absolutely essential to the experience, the contents of a page shouldn’t change depending on a device’s current orientation. The actual dimensions of objects may change to better suit the reader, but removing objects from a page or inserting new objects will only confuse a user.
Like desktop browsers, mobile browsers don’t all render code the same way. Making browser-specific adjustments to mobile websites can be a bit difficult. Gecko, Opera, and Webkit browsers can all be targeted specifically with some pretty ugly hacks. Luckily, up-to-date versions of these browsers typically do a good job of rendering standards-compliant code.
Internet Explorer Mobile has made huge strides in rendering code, but if you run into problems, there is a way to target IE Mobile in Windows Phone 7:
<!--[if IEMobile]> <link rel="stylesheet" href="ie_mobile.css" type="text/css" media="screen" /> <![endif]—>
While some developers loathe conditional comments, they have one beneficial attribute in a mobile environment: since this stylesheet is only loaded if a condition is met, a mobile device not running IE won’t make an additional request to load it. It’s also possible to use conditional comments so that on Windows Phone 7, only IE Mobile stylesheets are loaded (fewer requests, faster load-time).
On a desktop, the dimensions of a web browser can be defined by the user on-the-fly. The dimensions of browser window and monitor are independent from each other.
Desktop browser window and monitor display resolution are two independent attributes.
The mobile browser is limited to the width of the device. To compensate for small device dimensions, the viewport on a mobile device functions as an implied window. By default, many recent mobile browsers setup a viewport that accommodates the width of content on a page, and can be panned and zoomed.
The screen size shows the currently visible area of a webpage. The viewport extends out beyond the currently visible area, and can be panned and zoomed.
Top: In the top image, the viewport is automatically set by the mobile device, and the pixel ratio is low, making text difficult to read without zooming in. Bottom: In the bottom image, the viewport is set to the device width (pixel ratio of 1:1) and zooming has been disabled. Text in the bottom example is readable on page load.
Depending on the site, it might not make sense to force a user to browse in this fashion of panning and zooming. Many popular web applications have created polished mobile interfaces where panning and zooming would only slow down a user. For instances like this, we can actually control the viewport size on many mobile devices.
It should be noted that you don’t want to restrict panning and zooming on mobile devices for all websites. This is only a measure that should be taken if an experience is being designed specifically for mobile users.
Limiting mobile users to a 1:1 pixel scale of a site can lead to lots of panning back and forth to read text. Preventing a user from zooming in on a site not optimized for mobile viewing may lead to super tiny font sizes that can’t be read.
As users become more accustomed to browsing mobile versions of sites, they may grow tired of panning and zooming in favor of websites that have planned an experience specifically for them. Is it preferable to browse a news website where you’re required to zoom into the content area to be able to read it, or would it make more sense if the zoom level were automatically set so the content could be read as soon as a page loads?
Consider the mobile Facebook website. The mobile version of Facebook’s website restricts users from changing the scale of pixels on their site, and creates a fixed viewport the actual width of the device browsing the site. As a result, the mobile Facebook site functions much like a user might expect when running an application on their phone. The mobile Facebook website is incredibly easy to use on a mobile device because everything can be understood without zooming to specific navigation controls or content areas.
Facebook’s Mobile site functions like an application built for mobile devices. It doesn’t just feel like a website that can be viewed on a mobile device; it feels like a website built for mobile device interaction.
Setting up the viewport for mobile devices can be done using the <meta name=”viewport”> tag. A typical setup may like like this:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
This code sets the width of the viewport to the actual device width, sets the scale of pixels to 1px per actual pixel (1:1), and disables the users ability to scale the pixels. The viewport meta tag was introduced by Mobile Safari, and they have done an excellent job documenting these controls.
The Microsoft Kin was a smartphone platform unveiled April 12th, 2010. After two years of development, about $1 billion in development costs, and 48 days on the market, the Kin was discontinued. What was the problem?
There are probably a number of reasons why the Kin didn’t do well. I’d venture to guess that one reason is that the Kin smartphone wasn’t actually a smartphone. Smartphones have apps. The Kin did not.
The point is, users are creatures of expectation. Alright, that’s a bit shallow of a statement, but we’re also being shallow as designers if we expect to retain users after drastically changing an experience between devices. If a website is about cookie recipes on a desktop, it should also be a website about cookie recipes on a mobile device.
It’s very rare that you should omit content from a mobile device that would be displayed on a desktop. The most reasonable case for omitting objects from a mobile site is when the object wasn’t essential to the desktop site in the first place.
Mobile design isn’t about crafting an entirely new experience, but delivering the same experience, fine-tuned for handheld devices.
There are exceptions of course, or perhaps better stated as environment specific tasks. One obvious example of this would be an application that makes use of geolocation. While geographic location isn’t always useful data for a web app when using a desktop, location data can be very useful for mobile users. Consider applications like Foursquare and Gowalla that have built really clever experiences around user location data.
In instances where a task can only be completed on a specific device, it’s acceptable to not display that task/content. For the most part, these scenarios are few and far between.
In the next part of this series, we’ll be talking about interactions that are unique to mobile devices, and how we can use new frameworks to build interactions like swiping directly into our web applications. We’ll discuss when it’s appropriate to use these types of interactions, and how some desktop conventions don’t translate well to mobile devices.
Until then, thank you for the feedback on this series so far! I know that mobile design is an area of much debate. If you have thoughts on how we should be delivering mobile experiences, I hope you’ll share them in the comments below.
“The biggest way technology can disrupt art is by providing exposure for the artists. Right now to find emerging artists you’d have to know their specific name to search for them on Google or gallery hop every weekend in Chelsea. Artsicle helps the artists find exposure earlier and make the money they need so they can continue to be artists.”
-Artiscle Co-Founder Alexis Tryon
What is Artsicle? It’s a disruptive platform showcasing emerging artists to the world with a rental model for everyman art lovers. By joining Artsicle, users like you and me, who maybe don’t have time to keep up with the modern art scene and gallivant around Chelsea, can discover today’s top emerging artists. Users can rent original artwork for their homes for just $50 per month or start creating their own collections with prices as ranging from $500-$1,500.
Artsicle’s slick, new site launches today featuring 20 new artists, fresh out of their MFA programs, to add to the 10 or so established artists already on the site.
Aside from the heavy amount of inbound requests, Tryon finds fresh new talent through open studios and referrals, and “curates the artists more than the pieces.” In total, the new site includes 300 pieces in its collection. The original works are insured, but many of them can only be rented by New Yorkers, for now.
“The concept is really cool. This is an area that needs a lot of help as artists have problems connecting with collectors, especially outside of the gallery world,” says Brandy Carstens, the Co-Founder of Ground Floor Workshop, a Brooklyn based art space.
CTO Scott Carleton, a former nuclear engineer and CEO Tryon, an Ivy league educated art historian founded Artsicle in September 2010. The bootstrapped startup works out of NYC’s Dogpatch Labs and now includes Nicholas Greenfield, a front end developer and collage artist and sculptor Alfredo Achecar, who passionately sought out Artsicle to offer any help he could.
Artisicle is a win for artists who don’t want to sell their work on Etsy or Ebay. N.B. Etsy averages 600,000 pieces a day and the furthest you can sort your search to is “art.” While artists are slowly becoming more comfortable with being online, the membership model adds exclusivity without being really exclusive. Artsicle currently has 750 members from its beta period.
In comparison to Art.sy, a popular New York City startup that focuses on the high-end art market, Tyron sees Artsicle as its everyman version. “We are targeting people who wouldn’t have thought of themselves as art collectors,” explains Tyron.
Art.sy is similar to TurningArt, one of our recent Best of Boston Startups, which also rents art to consumers a la Netflix style. The difference is that TurningArt rents out prints, but your rental dollars go towards an art purchase, which Artsicle does not offer in favor of keeping its artists well-fed.
I had the pleasure of interviewing Alexis Tryon and Alfredo Achecar last week in Dogpatch Labs. Watch this video interview to hear more about technology’s disruption of modern art.
For real-time updates on the art market, follow Artsicle on Twitter.
