matt's posterous pacygas

plague88

Fandango Begins Rolling Out Mobile Tickets That Let Moviegoers Go Paperless

Waiting in line for movie tickets is still the worst part of going to the movies (unless you are going to see The Bounty Hunter). With so many mobile phone movie apps, it’s easy to find what’s playing at nearby theaters and even purchase tickets right from your mobile phone, but then you still have to get a paper ticket from the dispenser or the ticket agent. But your ticket could easily be delivered to your mobile phone via a 2D barcode.

Today, Fandango is launching a mobile ticket program in eight cities which lets moviegoers finally go paperless. Your ticket is delivered to your mobile phone in the form a of a 2D barcode, or QR code, which the ticket-takers can scan. Movie theaters need to equip their attendees with special scanners, which is why it is only available in a few markets. (MovieTickets.com is testing a similar program).

Here are the theaters participating in Fandango’s initial rollout:

  • New York: City Cinemas 1, 2 & 3, Angelika Film Center, East 86th Street Cinemas, Village East Cinema, Beekman Theatre, The Paris Theatre.
  • New Jersey: Manville 12 Plex.
  • Houston: Angelika Film Center.
  • Dallas/Plano: Angelika Dallas; Angelika Plano.
  • San Diego: La Mesa Grossmont Center, Clairemont Town Square Stadium.
  • Bakersfield: Valley Plaza 16.
  • Sonoma County: Rohnert Park 16.
  • Hawaii: Ward Stadium, Kahala Theater, Kapolei 16, Mililani Stadium.

Filed under  //   iphone   mobile  

8 Things That Suck About the iPad - apple ipad - Gizmodo

8 Things That Suck About the iPad

A lot of people are psyched about the iPad. Not me! My god, am I underwhelmed by it. It has some absolutely backbreaking failures that will make buying one the last thing I would want to do. Updated

Big, Ugly Bezel
Have you seen the bezel on this thing?! It's huge! I know you don't want to accidentally input a command when your thumb is holding it, but come on.

No Multitasking
This is a backbreaker. If this is supposed to be a replacement for netbooks, how can it possibly not have multitasking? Are you saying I can't listen to Pandora while writing a document? I can't have my Twitter app open at the same time as my browser? I can't have AIM open at the same time as my email? Are you kidding me? This alone guarantees that I will not buy this product.

No Cameras
No front facing camera is one thing. But no back facing camera either? Why the hell not? I can't imagine what the downside was for including at least one camera. Could this thing not handle video iChat?

Touch Keyboard
So much for Apple revolutionizing tablet inputs; this is the same big, ugly touchscreen keyboard we've seen on other tablets, and unless you're lying on the couch with your knees propping it up, it'll be awkward to use.

No HDMI Out
Want to watch those nice HD videos you downloaded from iTunes on your TV? Too damned bad! If you were truly loyal, you'd just buy an AppleTV already.

The Name iPad
Get ready for Maxi pad jokes, and lots of 'em!

No Flash
No Flash is annoying but not a dealbreaker on the iPhone and iPod Touch. On something that's supposed to be closer to a netbook or laptop? It will leave huge, gaping holes in websites. I hope you don't care about streaming video! God knows not many casual internet users do. Oh wait, nevermind, they all do.

Adapters, Adapters, Adapters
So much for those smooth lines. If you want to plug anything into this, such as a digital camera, you need all sorts of ugly adapters. You need an adapter for USB for god's sake.

Update: Why stop at 8? Here are more things we are discovering that suck about the iPad.

It's Not Widescreen
Widescreen movies look lousy on this thing thanks to its 4:3 screen, according to Blam, who checked out some of Star Trek on one. It's like owning a 4:3 TV all over again!

Doesn't Support T-Mobile 3G
Sure, it's "unlocked." But it won't work on T-Mobile, and it uses microSIMs that literally no one else uses.

Filed under  //   apple   mobile  

Korea’s First Android 2.0 Handset is the ‘Motoroi’ - Amazing!

Home Announcements Korea’s First Android 2.0 Handset is the ‘Motoroi’

January 18, 2010 Print Preview

Korea’s First Android 2.0 Handset is the ‘Motoroi’

The first Android 2.0 handset to arrive is Korea will be Motorola's "Motoroi".  Available exclusively through SK Telecom starting in early February, the Motoroi features an 8 megapixel camera, a 3.7-inch high-definition WVGA screen.  Speaking of high-def, the handset also features 720p video recording and  HDMI output to play your HD videos directly to your HDTV.    The cost of the phone ends up around 900,000 won, or $800 USD, which is right about the same price as the iPhone in South Korea's market.

MOTOROI is a smart phone without compromise, delivering a wiser, richer web and messaging experience with the most delightful touch-interface you have ever experienced, all made possible through the combination of Motorola’s expertise in design, a truly differentiated Android experience, and the power of SK Telecom’s network. - Sanjay Jha, CEO of Motorola Mobile Devices.

If the Motoroi looks a tad familiar to you, it's because we've reported it previously as the Sholes Tablet/XT701.  You guys feeling the hip on the side?

Source: Press Release

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

127792 Responses tohttp://www.androidguys.com/2010/01/18/koreas-first-android-2-0-handset-is-the-motoroi/Korea%27s+First+Android+2.0+Handset+is+the+%27Motoroi%272010-01-18+18%3A16%3A50AndroidGuys “Korea’s First Android 2.0 Handset is the ‘Motoroi’” Leave a reply ›

Leave a Reply

Filed under  //   mobile  

Windows Mobile 7 Rumor Explosion: Two Versions, New Name, First Hardware [Microsoft]

Windows Mobile 7 Rumor Explosion: Two Versions, New Name, First Hardware

As Mobile World Congress—and presumably Window Mobile 7—careens closer and closer, we're going to hear a lot more of this. Today's batch? Business and consumer versions of the OS, a sexxxy new name, and possible first hardware.

WMExperts' post is essentially a digest of everything they think they know from a variety of sources, including this very site. Even as a summary, though, it's pretty huge, and the rumors sprawl from totally ridiculous to fairly credible, so here are the meaty bits:

&bull Windows Mobile 7 won't be marketed as Windows Mobile 7. We sort of knew this already, since Microsoft has been marketing Windows Mobile and "Windows Phone" since the announcement of 6.5. But it's not even going to be that, apparently. The new name? "Seven."

&bull There will be two versions of the OS: one for OEMs and businesses, a stripped-down that's being referred to in development as Business Edition; and one media-oriented version for consumers, tentatiely called Media Edition. Business edition will be focused on enterprise tools, like collaborative document editing, while the media edition will be focused on, well, media.

&bull If we see Seven at MWC, it won't be a full product—we'll see HD video playback, a Zune-like media interface, and some of the rest of the UI, but not all of it. This sounds odd! But the rumor consensus is that the OS won't hit phones until late 2010, so it's plausible that they're just not done yet,

There's nothing earth-shattering here, and most of these rumors just prompt more questions. Perhaps the juiciest part of this whole mess, though, is the rumored hardware from LG and HTC. What's so great about the LG Apollo and HTC Obsession, assuming they actually exist? Well, seeing as they're supposed to be Seven launch devices, they represent the new baseline for Windows Mobile phones. And this baseline is high: WMExperts reports both have 1GHz+ Snapdragon processors, 3.7-inch AMOLED screens, and 512MB to 1GB of RAM. In other words, Windows Mobile 7's dumpiest handsets will be gutsier than anything you can buy today—something that will get less and less impressive the longer Microsoft waits to release this thing.

Anyway, if you're still feeling a little lost as to what on earth WinMo 7 may or may not be, WMExperts' breakdown is worth a read. [WMExperts]


Send an email to John Herrman, the author of this post, at jherrman@gizmodo.com.


Your version of Internet Explorer is not supported. Please upgrade to the most recent version in order to view comments.

Loading comments ... -/|\\\\\" /></div>
	</div>
	
	<div class=
In order to view comments on gizmodo.com you need to enable JavaScript.
If you are using Firefox and NoScript addon, please mark gizmodo.com as trusted.

Oh, about time MS. Pretty late to the mobile show. Bring on the competition!

Filed under  //   mobile  

Sender 11: Mobile screen size trends #mobile #trends

Over at mBricks my colleagues have put a lot of work into the device database (we work with WURFL data and contribute back as well as we can). I took the opportunity to take a closer look at screen size trends. The data I have covers about 400 different device models sold from 2005 to today.

This shows the the most significant screen sizes, from the smallest to the largest. I have added a couple of upcoming phones as well, they are the ones with the dotted lines.

Over the years the relative screen size difference has increased. The difference between the smallest (128 x 128) and the largest (800 x 480) is now a factor of 23. That means the largest screen is 23 times bigger than the smallest one.

You can see that the smaller screens have a portrait orientation and the large screens have a landscape orientation. Between them are the phones that can change orientation, they can work in both landscape and portrait. 240 x 320 is the dominant screen size overall.

Resolution

I did a rough dpi (ppi to be exact) calculation for some popular phone models. The pixel density actually increases when the pixel count increases. The screens are not only getting bigger, they are getting sharper at the same time.

There is an upper limit to what dpi is meaningful. At a certain density, the eye can no longer see any difference. If the specs are correct, the upcoming Sony Ericsson Xperia X1 will have a pixel density of 298. That is the highest I've seen on a mobile phone yet. The human eye can resolve about 340 dpi at one foot viewing distance IIRC, but tests show that most people don't see much difference between a 150 and a 300 dpi image. So 298 dpi should be plenty.

Unfortunately, for LCD screens, increased pixel density doesn't give us more brightness. More brightness makes the screen easier to read outdoors and is more important than resolution from a usability perspective. OLED displays will help with this, but we are drifting off topic.

 

Yes, a grand total of 26 different screen sizes. I only counted phones that had a color screen, ran Java and had a browser.

As you can see, just a handful of variants makes up the majority of phones. Lets take a look at them:

 

It is obvious that 240 x 320 (also called QVGA) is on a roll. It is by far the most common and it is growing rapidly. If you develop, this should be your target screen size.

 

When you develop, you primarily need to worry about the width of the screen. For most practical purposes, the height takes care of itself. I have lumped together 176 x 208 and 176 x 220 for this graph. There is still a lot of them in the market, but their numbers have been decreasing since January 2007. In 18 months this screen size may be out of the market. Nokia haven't launched a phone with this screen size in 1,5 years. I have also lumped together 128 x 128 and 128 x 160.

Phone screen sizes has had a tendency to come in pairs. Each manufacturer had their own variation on large-screen high-end models and small-screen low-end" models.

Manufacturer small screen big screen
Sony Ericsson 128 x 160 176 x 220
Nokia 128 x 128 176 x 208
Samsung 128 x 160 176 x 220
Siemens 130 x 130 132 x 176
 

Individual variations is disappearing, the trend is:

Manufacturer small screen big screen
Everybody+dog: 240 x 320 ?

 

The majority of odd-sized screens are disappearing. No phones with the above screen sizes have been introduced for at least 4 quarters.

The dead and dying are partly BenQ-Siemens (who has left the market), partly the old Sony Ericsson P-series and partly the Nokia hires versions: E60/70 and N80/90.

The odd ones

What about the other ones, the not so popular, but not dying? These are the ones that do you in.

Fashion phones:
128x220 Samsung F210
240x400 LG favorite. Prada and Viewty.
Handheld touchscreens of the iPhone variety:
240x440 Various Palm and HP
240x480 LG KF700
Typical Palm/Blackberry form factor. US enterprise with portrait or square displays:
240x240 Samsung F210
240x260 Blackberry Pearl 8100
320x240 Various
320x320 Palm and Samsung
Clamshell:
640x480 HTC X7500, Qtek 9000, etc.
800x352 Nokia E90 Communicator
800x400 Sony Ericsson Xperia X1
 

Future

What will be the dominant screen sizes in the future? Well, the 128 width screen sizes are moving down from feature phones to basic phones and there are very few manufacturers that still uses 176 width screens. It looks like 240 x 320 is the new base line.

What will the dominant large screen size be? Let's hope there will be one. Right now there are a lot of different ones, every manufacturer has their own and I can't see a clear trend. The two hottest form factors right now is the handheld touch screens (ala iPhone) and the QWERTY clamshell (ala HTC).

For the handhelds, the 320 x 480 iPhone size is a possibility. It has an ok resolution for a 3,5 inch size. The Nokia "Tube" phone will have a 360 x 640 size (my estimate) and is another possibility.

For the clamshell form factor, 640 x 480 screen size would be my bet.

About the data

The data includes all the 400 different phone models sold in the Norwegian market from 2005 to 2008. I've given them four quarters of life time past the quarter they were introduced. That means an average of 14,5 months. This might be a little short.

I have left out basic phones. Only phones that has a color screen, support for java and a browser are included.

The Norwegian market is not very different from most other European markets. It's GSM only, the majority of handsets are sold with 12 month operator binding. Sony Ericsson, Nokia and Samsung are market leaders. Motorola is weak, HTC is up and coming in the enterprise market. The data includes the iPhone even though it has no official distribution. There is quite a bit of "black" iPhone imports.

Reliable sales figures for each individual device is not available, so the data is not weighted on popularity. But I don't think popularity would give a very different conclusion. I've checked "top ten" lists where available and none of the "odd" screen sizes seem to be big sellers.

Note: all sizes are written as width x height. So a 240 x 320 screen is portrait while a 320 x 240 screen is landscape.

Filed under  //   UX   Usabilty   mobile  

Mobile Web Design: Getting to the Point - Part II | mobiForge

Mobile Web Design: Getting to the Point - Part II

Section Feature image
Posted by paulca 1 year 9 weeks ago

Following on from part I, I want to put into practice the principles that I isolated by looking at GMail, Twitter and Facebook. I’ll apply the principles to one of the most common of web applications: the online store. I want to look at three typical online store pages and then go through some ideas about how best to apply mobile web design principles to the pages.

I'll go through the process of building the site from the ground up... from simple sketches through wireframing and the final design.

I've used 240×320 as a guide screen size while mocking this up. Because of the massive range of mobile device sizes out there, it can become impractical to support every single screen size out there. (For a deeper screen-size analysis, the DeviceAtlas Data Explorer does a great job of providing useful analytics such as this). 240×320 strikes a balance of practicality and the assurance that your site will look good on a good set of mobile handsets. It's important to note here that compared to modern desktop screen sizes, this is tiny; it's about one tenth of the usual available size. The image below illustrates just how much smaller this actually is:

Reflecting on the search page (above), the single most important thing is the results, so they should be given the highest priority. Any subsidiary elements, such as the search field itself, do just fine below the results. We have kept a one liner that tells the customer what they searched for and how many results there were, although this could be further simplified if desired.

main.js.txt710 bytes

Filed under  //   UX   Usabilty   mobile  

Effective Design for Multiple Screen Sizes | mobiForge

Effective Design for Multiple Screen Sizes

Section Feature image
Posted by bryanrieger 1 year 3 days ago

So you're a designer and have been tasked with the design of a mobile web site. Chances are, unless you're designing for only one device you're quickly going to be faced with a common problem experienced by designers who work with mobile devices; figuring out what screen size to actually design for.

For instance:

  • The iPhone is 320 pixels wide by 480 pixels high.
  • Many Nokia N-Series devices are 240 pixels wide by 320 pixels high.
  • Newer devices often support a landscape mode where the width and height are spontaneously reversed.
  • Older (yet still popular) Nokia devices have displays ranging from 176 by 208 pixels up to 352 by 416 pixels.
  • Blackberry screen resolutions range anywhere from 160 x 160 pixels all the way up to 324 x 352 pixels.

Screenshots of the BBC, Zipiko, XBox and UPS mobile sites.

This article is intended to help you develop effective design strategies to target a diverse range of mobile devices and screen sizes. To this end, we begin with an outline of two key issues you will encounter when designing for small screens—the diversity in screen and pixel size.

Expect and manage diversity

At this point you're probably asking yourself "...is it really necessary to design for all of these difference screen sizes?" or "...do I really need to create a separate design for each variant?" Depending on the business requirements of your project, it may be completely feasible to design only for one screen size—or in fact one device. However, if requirements dictate that the application (or web site) be usable by a majority of devices, you're going to have to find some way to deal with this diversity.

But wait, things may not be as bad as they first appear. When designing for the mobile web we can assume that pages will scroll up and down—as they do within desktop browsers. This somewhat removes the need to worry about the height of the screen, allowing us to primarily focus our efforts on dealing with the diversity found in device screen widths. Fortunately DeviceAtlas Explorer provides us a means to quickly visualize how the screen width property actually breaks down across the thousands of known devices.

Graph from DeviceAtlas Explorer showing number of devices based on the screen width property.

As the graphs above indicate, the vast majority of devices share just three screen widths; 128, 240 and 176 pixels—with many of the remaining values; 120, 130, 160, 208 and 220 pixels—not diverging too far from these three core values. That leaves us with a few devices at both the high and low ends of the spectrum with a width of 96, 101, 320 and 320+ pixels. While devices with screen widths of less than 128 pixels may seem a small percentage of the whole, when combined (96, 120, 101 and 84 pixels) they add up to 469 devices! Over half the number of 240 pixel devices—or about 10% of all known devices!

Chart showing percentage of devices with various screen sizes.

It's probably also worth noting that at this time, less than 5% of devices have resolutions greater than 320 pixels wide. Expect this to change over the next few years as we're now seeing smaller screen resolutions (128, 176, etc) give way to the larger (240+); as illustrated in the following chart.

Graph comparing screen width and year released properties from Device Atlas Explorer.

Considering screen size is important but there is one additional parameter to consider—the physical dimension of the screen.

The 'Problem With Pixels'

For years, designers have primarily been creating visuals for large desktop devices. Screen sizes averaging 1024 x 768 pixels have become the norm and although physical display sizes vary; the overall dimensions typically result in a pixel density of about 85 ppi (pixels-per-inch). Lately however, the display landscape has begun to change;

  • 'Netbooks' such as the Asus Eee PC 900 have displays in the range of 9" diagonal with a resolutions around 1024 x 600 pixels giving them pixel densities of about 133 ppi.
  • The Apple iPhone has a screen resolution of 320 x 480 pixels which when combined with its 3.6" diagonal display results in a pixel density of 160 ppi.
  • The E60 from Nokia has a screen resolution of 416 x352 pixels packed into a tiny 2.2" diagonal display giving it a whopping pixel density of over 240 ppi!

When combined with the need to support many devices, this wide variance in pixel density introduces a new problem; the impact of pixel size on design.

The following illustration simulates the same 100 x 100 pixel image on devices with pixel densities of 72, 144 and 240 pixels-per-inch. Notice how type and fine details are lost as the image is rendered smaller and smaller.

Illustration showing a simulation of images viewed on 72, 144 and 240 ppi (pixels-per-inch) screen resolutions.

Fortunately the race for "most pixels ever" has slowed and we're not seeing too many devices with pixel densities over 200 ppi. From a practical point of view, this means that it is unlikely you will have to support the very wide range of pixel densities illustrated above. It is however important keep in mind that not all pixels are created equal, and where possible:

  • Determine the full range of pixel densities you will need to support.
  • Review your designs on these devices to ensure critical detail is not lost.
  • Design and define layout elements based on relative units such as ems and percentages. This will provide the team with a truer indication of the size and relationships between layout elements.

This 'problem with pixels' is sure to become more widely discussed in the coming years as handset vendors seek to build new levels of flexibility into their operating systems. In fact, Google's Android has already implemented a ">potentially interesting solution to the problem of pixels. The Android operating system is based on abstract 'dp' (density-independent pixel) units which are completely relative based on a 160 ppi screen density. This allows designers to specify fonts and a host of other interface elements in a relative manner with the knowledge that they will naturally adjust to suit the device.

With an understanding of the diversity in screen size and pixel density, we now outline strategies you can implement today to build scaleable mobile web sites.

Strategy 1: Define device groups

As we discovered earlier, while there may be thousands of device models, the diversity isn't as bad as it may have first appeared. In fact, it's entirely possible to group many devices with similar screen widths together and to end up with five distinct device screen width groupings:

  1. tiny: 84, 96, 101, 128, 130, 132
  2. small: 160, 176
  3. medium: 208, 220, 240
  4. large: 320, 360, 480+
  5. desktop: 800+

These groupings are of course, entirely arbitrary and your project's requirements may dictate a different set entirely. For example; 320 pixels for the iphone and above, 240 pixels for more recent mobile browsers, and 128 pixels for older devices. In the end, defining device groupings really comes down to the goals and audience of the project. To this end, it's a good idea to visit DeviceAtlas on a regular basis in order to survey the device property landscape and reassess the relevance of your groupings.

You may also find that the development team will choose to create their own groupings based primarily on device capabilities. These are often described in a class based system where technical features (or limitations) are graded into categories that enable developers to only deliver a given functionality to devices that are capable of supporting it. For instance a 'Class A' device might be capable of supporting an advanced CSS spec, DOM manipulation and Javascript—while a 'Class C' device might only be capable of rendering basic XHTML-MP and rudimentary CSS. Be sure to consult regularly with the developers on a project to ensure that your assumptions and device groupings are compatible with theirs.

Strategy 2: Create a default reference design

After you've defined your device groups (and consulted with your developers) you're probably in a good position to select your reference device. This is the device that will serve as default during the design process and will ultimately lead to the creation of a reference design. Depending upon your business requirements you may wish to design reference versions for a medium (240px) screen size. This keeps the design simple enough to adapt to smaller screens, while allowing for a little more creative freedom on devices with larger displays. It's also not uncommon to choose more than one reference device and consequently, create more than one reference design (often based in some way on the device groupings described earlier.) This allows you to:

  • progressively enhance the design for more advanced devices (ex: to take advantage of GPS, an accelerometer or CSS3 support),
  • deal gracefully with devices that support differing models of manipulation (ex: touch devices), or
  • adjust the design to compensate for severe limitations present on more restricted devices.

A reference design is necessary to serve as a basis for adaptations to other devices.

Strategy 3: Define rules for content and design adaptation

Once you've completed a reference design you should also provide specific direction for adaptation of this design to other screen sizes. Similar to the contents of a visual design document, these rules and guidelines should assist the development team in actually implementing the design in code. For example;

  • The site logo should be replaced (or adapted) for each device grouping to ensure image clarity.
  • Headers should stretch to 100% of the screen width using the supplied background image where possible.
  • Content images should be no larger than 200px wide for the 'default grouping' (or 80% of the device's screen width).
  • Content images should be automatically scaled and optimized to screen width if an alternate does not exit.
  • List icons are not to be used on displays smaller than the 'default grouping' in order to make as much space available for the actual content.
  • A dynamic style sheet is to be used in order to set many values on-the-fly for each device, and cached appropriately.

While not a formal recommendation, the above outlines common strategies to adapt and enhance design while keeping file sizes to a minimum. Always make design decisions based on the unique audience, goals (and challenges) of your project.

Define rules to indicate how a component of your design is intended to be adapted.

Strategy 4: Opt for web standards and a flexible layout

With the reference design and adaptation rules in place, the final strategy builds flexibility into the markup itself through the use of generic, standards based XHTML and CSS. In practice, this means creating markup that uses the tags and structures inherent in HTML (i.e. headers, paragraphs, lists and divs) to define the structure of your page. The immediate benefit—any browser that can read HTML will be able to display your content and will assign it an (albeit rudimentary) visual style. Given the vast number of mobile devices, this benefit cannot be underestimated as it ensures your content will be accessible to a large number of users without too much higgery-jiggery on the part of developers. You will then be in a great position to progressively enhance the design for different device groupings through the use of browser and/or device-specific CSS, graphics and scripting.

As described in the previous section, the content and design adaptations you choose to implement will vary depending on the project. Actual page width however, is one aspect that will typically not require formal adaptation. The issue of fixed versus fluid (or flexible) width designs has long been a topic for debate with web designers. The arguments tend to revolve around optimal text line lengths, wanting (or not wanting) the browser to fill the entire screen, and rendering issues related to large window width variances.

With the mobile web, these concerns don't weight in nearly as heavily. Line lengths are often too short regardless, there simply isn't enough screen real estate to have more than one useable browser window open at a time, and there isn't likely to be the extreme changes in width that might be possible with a desktop browser window. In fact, fluid designs lend themselves really well to mobile devices as they work beautifully with low-bandwidth design techniques that maximize the use of CSS and XHTML. These include:

  • Not specifying a specific document width, thereby enabling the design to expand and contract naturally to fill the screen.
  • Taking advantage of block elements which will also natively expand and contract.
  • Using CSS background colours and tiled images to style layout and content elements.
  • Specifying the size of layout elements using percentages so that they naturally expand and contract to fit page width.

Putting it all together

The following example from bbc.co.uk shows many of the design and adaptation strategies we have discussed in action. Let's first look at the XHTML markup.

<h1><img src="/mobile/images/hp-colours/tiles_greenblue.gif" width="75" height="34" alt="" border="0" /></h1>
  <!-- Editorial promo -->
  <h2>Featured</h2>
  <div id="topPromo"><img src="20081201180906.musicnews_mobile.jpg" width="170" height="96" alt="" border="0" />
  <p>Latest episode: La Roux, Kasabian and Jack Penate</p></div>
 
  <!-- News feed promo -->
  <h2>BBC News</h2>
  <div><img src="http://news.bbc.co.uk/media/images/45348000/jpg/_45348804_tank_getty226x260.jpg" width="66" height="49" alt="" border="0" />
  <p>Israel 'expands' Gaza offensive</p>
  </div>
 
  <!-- end News feed promo -->
 <div>
  <ul class="linkList">
  <li class="linkText">European gas supplies disrupted</li>
  <li class="linkText">Warnings issued amid Arctic chill</li>
  <li class="listMore">More top stories</li>
  </ul>
  </div>

The BBC markup is simple, standards compliant and relies on standard XHTML tags to define the structure of the content. This ensures that the basic content (consisting in this case of several headers, body copy, images and an unordered list) will be rendered—regardless of the device or browser. CSS is then used to style the content.

h1 { 
padding: 3px;
background: url(/mobile/images/hp-colours/banner-bak_greenblue.gif);
background-repeat: repeat-x;
background-color: #00594d;
color: white;          font-weight: bold;
font-size: small;
}
 
 
h2 {
color: #027063;
font-weight: normal;
font-size: medium;
padding: 2px;
background: url(/mobile/images/newimgs/h2-bak.gif);
background-repeat: repeat-x;
background-color: #ecedee;
border-bottom: 1px solid #c1c0c0;
}
 
 
h2 a:link, h2 a:visited {color: #027063;
font-weight: bold;
text-decoration: none;
}
 
 
h2 a:hover, h2 a:active {
color: #333333;
text-decoration: underline;
}
 
<;/pre>;
  <;pre id="line">;/* New promos */
#topPromo {
background-color: #000000;
}
 
 
#topPromo p {
color: white;
font-size: small;
border-top: 1px solid #757474;
padding: 2px;
}
 
 
#topPromo a:link, #topPromo a:visited {
color: white;
font-size: small;
display: block;
text-decoration: none;
}
 
 
#topPromo a:hover, #topPromo a:active {
color: #8ad3ca;
font-size: small;
display: block;
text-decoration: underline;
}
 
.linkList ul {
border-bottom: 1px solid #c1c0c0;
}
.linkList li {
padding: 2px;
padding-left: 19px;
margin: 2px;
}
.listTxt {
background: url(/mobile/images/newimgs/ico_txt_on-fff.gif);
background-repeat: no-repeat;
background-position: top left;
}

As you will note, the layout is entirely fluid. No set width is assigned to the page body, masthead, headers, lists or paragraphs. As seen in the example below, this results in a layout that performs much of the required adaptation on its own; simply scaling as needed to suit different screen widths.

The same fluid layout viewed within desktop and mobile versions of Safari.

The remaining styles and content are then specifically adapted server-side to suit the device or family of devices.

Illustration of adaptation points within a design.

  1. The logo is resized or replaced to suit the device screen width.
  2. The masthead uses both a tiled and coloured background. Older devices like the Nokia 6680 which feature less sophisticated browsers are unable to render the tiled background but do display the background colour. Even simpler devices supporting only WAP 2.0 (XHTML-MP) may ignore both style properties altogether and simply display the logo. (Note that in the BBC's case, this causes a problem as the white logo is then displayed on white; rendering it somewhat illegible).
  3. The BBC seems to have chosen to tailor the editorial to specific devices (or device groupings). While the iPhone includes a large 'Feature' item promoting music downloads, other devices jump striaght to the display of today's top 'BBC News'. This editorial decision may be due to the iPhone's flat data and strong podcast and media support but could also simply be due to its larger screen size. Were the 'Feature' displayed on a Nokia 6680 for example, it would take up most of the display forcing users to scroll to see today's top news stories. This decision is also counterbalanced by the reformatting of content further down. While all three news stories are displayed on the iPhone, only one includes a photograph. This once again enables all the top news content to be seen without scrolling.
  4. Images are scaled or replaced to suit the width of the display.
  5. On larger devices, icons are associated with each list item. While not visible in the example below, this stylistic element is removed on smaller devices ensuring a comfortable line length for the accompanying list copy.

A balanced approach

The BBC web site is an ideal example as it shows how simple it can be to combine clean markup with well conceived styles and strategic editorial decisions to achieve a great experience on a wide range of devices. Ultimately, your design, adaptation and editorial choices will be based on many factors including your budget, target audience and the functionality of the mobile web site you are designing. In the end, it's all about striking a balance between the creation of a well optimized, fast-loading site and the delivery of great, targeted content to your users.

For an in-depth look at the what makes a truly great mobile application and the design of mobile web sites from a user interface, functionality and usability point of view; be sure to read Mobile App Design: Getting to the Point Part I and Part II.


Filed under  //   UX   Usabilty   iphone   mobile  

AT&T messes with plans in wake of Verizon's moves, slashes unlimited voice p...

via Engadget by Chris Ziegler on 1/15/10

Sprint's talking about it, but AT&T's straight-up doing something about Verizon's plan adjustments this morning with a series of its own tweaks this afternoon. Starting Monday, January 18 (conveniently the same day that Verizon's changes go live), unlimited talk will run $69.99 on individual plans, a nice little cut of $30 against the $99.99 the carrier charges today; family unlimited, meanwhile, comes in at $119.99. Unlimited talk and text costs another $20 on top of unlimited talk alone -- no change from the current add-on pricing. Similarly, unlimited talk plus smartphone data goes for $99.99, meaning that you're paying $30 for the data package -- exactly the same as you're paying now, so really, this all boils down to a big adjustment in what carriers across the board are charging for voice. The principles of Econ 101 have us believe that voice isn't as popular as it used to be -- we are now sending billions upon billions of texts, after all -- and as we ease off the voice infrastructure, it makes sense that these guys would want to upsell everyone into unlimited plans (remember that we're living in an "all you can eat" kind of nation) while still banking big on precious kilobytes and characters. Well played, AT&T; you too, Verizon. Well played, indeed.

AT&T messes with plans in wake of Verizon's moves, slashes unlimited voice pricing originally appeared on Engadget on Fri, 15 Jan 2010 17:16:00 EST. Please see our terms for use of feeds.

Permalink   |  sourceYahoo  | Email this | Comments

Filed under  //   iphone   mobile  

Location, Location, Location: 5 Big Predictions for 2010

GPS-aware mobile devices have become commonplace, which means connecting the dots between what you’re doing and where you’re doing it is easier than ever.

In 2009, location-sharing applications finally emerged in user-friendly formats, altering the way we think about where we are and helping us understand more of the meaning behind the data in aggregate.

Technology early adopters showed a predilection towards mobile location-based games, discovering that check-ins could mean something and that being the mayor of a venue might earn them a free drink. Now that businesses are actively exploring the opportunities that these location-aware services provide, we’ll see location matter more than ever in 2010.

1. Facebook Status Updates Will Become Location-Aware

The writing is on the wall. Facebook is the world’s largest social network, and for the first time ever it was the most trafficked web site on Christmas day in the United States. If anyone is poised to make a big move in the location-space in the new year its Facebook.

Facebook is already encouraging members to be more open. They made a bold and controversial move to alter the default settings around status updates in the hopes of making more Facebook updates public and searchable.

In the same spirit of openness, Facebook would certainly profit by implementing opt-in location-aware status updates. Knowing where your Facebook friends are grabbing a cup of coffee or catching a flick is a just as important, if not more so, than knowing that they’re doing it. So in much the same way that Foursquare shows you check-ins from friends and people checked in at venues, Facebook could provide context around status updates in the wild, but on a much grander scale.

2. A Popular LBS App Will Be Acquired

Once considered merely novelty apps, location-based mobile applications and games have demonstrated clear value in 2009. Mobile and web users have finally demonstrated that they’re interested in sharing their locations (in the form of places or venues as opposed to lat/longs). With the right privacy settings or gaming incentives, services are catering to businesses who are now offering location-based deals, and aggregating data around where people congregate is becoming increasingly desirable.

When those factors are combined with the crop of applications who get location-sharing right, and an economy on the upswing, you get an environment ripe for acquisitions.

So, who looks good for acquisition? Loopt. While Loopt is still struggling to make up ground in the blogosphere after losing buzz to newcomers with a focus on gaming, like Foursquare and Gowalla, the company has made huge improvements to their iPhone app (and introduced BlackBerry and Android apps).

Loopt has even adopted a check-in model, added tips to place pages, and will explore additional gaming functionality as well. In fact, their recent acquisition of GraffitiGeo is what gave rise to the new Tips functionality. Since GraffitiGeo also includes badges and “Street Cred” to measure identity and encourage participation, you can certainly expect similar elements to make their way into Loopt in 2010. Clearly the Loopt of today is drastically different from the Loopt of years past.

What makes Loopt extremely attractive, however, is their massive user base which includes millions across more than 100 different mobile devices. Loopt dwarfs the competition in this arena.

And who will be in an aquiring mood? Two big companies come to mind: Google and Microsoft.

When looking at the events of the last year, Google has shown clear interest in location, especially with the introduction of Latitude, which bears a striking resemblance to previous iterations of Loopt (i.e., primarily map based, and not place-specific).

Unfortunately, Google is already way behind in the location space. Even with the addition of location history and friend alerts, Latitude is lackluster and still without a native iPhone app. But, Google has shown a propensity of late towards acquiring companies that give them a competitive advantage in a yet untapped space.

Whether or not Google buys Loopt, everything points towards Google taking big leaps on the location front in 2010. We know they were interested in buying Yelp, and we know that they’re more actively trying to expose their Place Pages product, even encouraging locales to use QR code window decals so patrons can look up information on that particular venue on the spot (and perhaps check-in at a later date?). It’s certainly not a stretch then to assume that Google is interested in further assimilating the Latitude and Place Pages products into a more full-fledged location and recommendation service centered around places. An acquisition like Loopt would help them connect the dots much faster.

Microsoft could also make a play to become recognizable in the location space. They’ve yet to make a splash, but they do have an excellent maps application (especially as a part of their Bing iPhone app), and they tend to try and compete with Google at every possible juncture.

One company that we probably won’t see get snatched up in 2010 is Foursquare. They’re currently riding high on buzz, building up a user base in populous metros, and looking to expand worldwide. While they may be ripe for acquisition, history tells us that Foursquare’s co-founders will want to stay independent. Their previous product, Dodgeball — a mobile location-based game ahead of its time — was acquired by Google and all but ignored until its final demise.

We have noticed that Foursquare and Twitter have become quite close, most likely because Jack Dorsey, Twitter’s creater, is an investor, so we do expect more synergies to develop between the two companies in the coming year.

3. Twitter Will Build Their Own LBS app

In 2009 Twitter beefed up their product. Deciding that some things shouldn’t be left to third-party developers, Twitter modified their simple yet powerful platform in a few unexpected ways. We’ve seen the addition of a formal standard for retweets, powerful new Twitter Lists functionality, and even a mobile client of their own. In 2010, we expect that Twitter will continue down this path and build a location app of their own.

Twitter’s already laid the foundation when it comes to location. In September Twitter became location-aware, with opt-in settings enabling Twitterers to tag their tweets with their location. Then in November, Twitter announced a Trends API, opening up trending data specific to locations (i.e., trending places) to developers.

Twitter’s recent acquisition of Mixer Labs is the most telling indication that they’re exploring building their own location-aware applications. Mixer Labs, who’s popular GeoAPI service does reverse geocoding to identify places, supports a places finder for the 16 million business-strong database, and includes media layers to add context — think Flickr photos, YouTube videos, even Foursquare check-ins — to neighborhoods.

Twitter will certainly pass along this souped-up geo offering to developers at a cost similar to GeoAPI’s pricing scheme, but they could also be planning to build their own app for even more lucrative opportunities.

One such application we envision would be a feature addition that is rolled up into Twitter’s business services. So as a paying business user of Twitter, your dashboard view could show you valuable context around location-aware tweets happening in or near your place of business.

4. Location Sharing Will Become Ubiquitous

In some ways location is already ubiquitous. It’s already built in to most of our favorite applications. When we use Yelp’s mobile app, we can find nearby restaurants. If we share our location with Flixster on our mobile devices, the app shows us movies and theaters that are within a certain radius. Even Evernote tags notes created on mobile devices with location metadata so that if you want to find notes you created in a certain place, you can.

Location is relevant in almost any equation, which means applications, web sites, and services will push to integrate even more location functionality. A Google search for something like “food” already returns local place results based on your IP address. Are we that far off from the same search returning both places as well as real-time tweets from people nearby on food? The answer to that question is a definite no.

As we move into 2010, the value of shared location data will only be as strong as the quantity of people sharing location-aware updates. Twitter, Foursquare, Loopt, Gowalla, Google and potentially Facebook will help contribute to the tide that pushes more people into the sea of location-sharing.

5. Location Will Be Both Media Darling and Cautionary Tale

Those of us who have been using Twitter for some time have followed the course of the micro medium’s macro coverage in the news. Before 2009, and even up through the first few months of the year, Twitter was gravely misunderstood by the mainstream media.

One thing was apparent: Twitter was changing the pace of news, becoming the platform for citizen journalism, usurping the entertainment media’s hold over celebrity news, and evolving into a medium for businesses to set up shop.

As such, the media came a calling, at first with extreme consternation and disdain. But as the stories continued to flood in, they started appearing as headline and front-page stories. Eventually the mainstream media changed their tone. Expect the same course of events to follow the location-based service and application space in 2010. Location will make headlines in 2010.

It’s the nature of the mainstream media to show up late to the party, so while Foursquare and Gowalla continue to make headlines in the blogosphere, those services aren’t getting the same coverage in newspapers or airplay on TV. This will change in 2010. We can expect location-sharing to be both mocked and celebrated in the new year. Stories of location-sharing gone wrong will be described as cautionary tales for those who live their lives too openly. Those stories will be followed by general interest pieces on the value of connecting through location, or success stories highlighting businesses able to capitalize on location-based services.

Image courtesy of iStockphoto, allsee

Filed under  //   mobile   web strategy  

iPhone and Android Are Taking Over the (Mobile) Internet [Smartphones]

So, what does it take to snatch a combined 75% of US mobile internet traffic? Two operating systems, a handful of phones, and one great browser core.

That the iPhone is a massive source of online traffic isn't a surprise—that's been apparent since the week it launched. What's interesting here is Android's rise, which is dramatically quickening, already accounting for a fifth of mobile traffic in the US, when the real marketing push for the OS, starting with the MyTouch ads and the massive Droid launch, is only recently starting in earnest. What is a surprise, or at the very least a Sad Thing, is how poorly Palm is faring. Their tiny sliver of market share might seem understandable since they really only had one new phone for the duration of the survey, but this phone was supposed to be their savior; in the year since it was introduced, their mobile traffic actually fell.
Google and Apple's stark gain in the stats, collected by mobile advertising firm AdMob, is a little less spectacular worldwide, mainly because Symbian's established, but waning, 40% smartphone market share helps it snatch about 25% of mobile web traffic. Still though, two things are clear: Android and the iPhone are who mobile web developers are going to have to cater to, and WebKit, which Symbian uses in its browser too, is basically it.

Anyway, how about a bonus chart! Ever wondered how common the different Android handsets are, which is most popular, and which don't register? Well hello, extra pie:

The G1 is the predictable star here, but the Droid is exploding. [AdMob via Techcrunch]


Send an email to John Herrman, the author of this post, at jherrman@gizmodo.com.

Filed under  //   google   mobile   web strategy