On Mon, 4 Jul 2005, John Whelan wrote:
> I think Curt's comments reflect my point exactly that mobile browsing IS
> different.
You know what? Thinking about this further, and looking at the way I and
people I know use the mobile web, I don't think I buy this one at all. I
think that the only reason Europeans think that it's different is that
they've they've never had capable phones using compatable protocols.
Here in Japan, the content, while different in some areas simply because
they aren't applicable to the real web, such as ringtones, is pretty
much the same in most areas. What do people do on their phones here?
They read news sites, and blogs, and articles. They do their banking.
They look for restaurants. They use price comparison sites. They find
maps to places.
All of these work pretty much the same way whether you're doing them
on a PC or a mobile site; the only difference is that the mobile site
needs to be presented with much less glitter and chrome than we're used
to these days, and just give up the straight content. But that's not
hard to do and requires no special technology, as imode has proved: it
requires simple, standard HTML that has been in common use for well over
a decade now. You provide that, and don't wall off your garden, and
everybody will fall all over themselves to make fine mobile sites for
you.
Given the technology of 1995, there's nothing at all hard about making
mobile websites; just make the PC web site or gopher site you'd have
made ten years ago. Anybody can do it.
The one thing I would say is qualitatively different is that I, at
least, tend to browse in smaller chunks of time somewhat more often:
more so when using my keitai than my PC (though I still do this on my
PC, too!), I'll read part of an article, stop for a few moments (as I
change trains, perhaps), and then start again. But bookmarks and screen
memos take care of that quite nicely.
> Trying to render fixed web sites on a mobile will never work as
> fixed web will by its nature always be ahead and support features not yet
> available on most handsets.
Actually, though it's not ideal, rendering fixed sites can work pretty
well, as Google has shown. I use it all the time for reading news and
articles and so-on from PC websites.
And this is what Google has always done quite well: removes barriers
between you and the content. That's why they're the most popular search
engine in the world and Altavista (remember Altavista?) is nowhere.
> Sorry you didn't stay till the end of our flash demo you might have
> learnt something.
You darn well ought to be sorry. You ought to be so sorry that you're
firing your marketing department. It's about ten times worse for you
guys than other companies because the mobile web is all about stripping
off chrome and getting down to content, and your web site is doing the
exact opposite.
> It is difficult to explain a very new idea like this in a few
> seconds....
Yeah, but two minutes of silly animations without even beginning to
explain the idea? This is not a problem with your idea being hard to
explain; this is a problem with you not even trying to explain it, at
least not before my patience ran out.
Think about it: I was watching that video for several times longer than
I spend on a typical web page. (Have you ever noticed that people spend
about the same amount of time reading or using a PC and a mobile web
page? You read the text or you fill in the form and then you move on.)
> ...and our marketing is always open for improvements.
Here's my suggestion: just write up, as text and a few simple images,
what the heck a mobile user experiences when he uses your product.
Something like this:
A user, wanting a restaurant coupon, goes to the Tabemo web site,
via a bookmark, a link from his e-mail, or entering the URL. He
sees a menu that allows him to browse by area, type of food,
discount, or time he wants to eat. [Insert screenshot here.]
The user iteratively narrows down his selection from a list.
[Further screenshots: clicks "Shinjuku," gets a list of food types,
clicks "Chinese."]
The user is eventually presented with a list of coupon offers
listing the restaurant name and the type and amount of the discount.
[Screenshot of six or seven offers.]
The user then clicks on an offer to see the details. [Screenshot of
an offer detail screen, containing restaurant name, times the coupon
can be used, whether reservations are required, etc. There are links
to further information about the restaurant, a map to the restaurant,
a "take coupon" button, etc.]
User clicks on "take coupon," it's saved in his current coupons list
(accessable from the top page), and he's shown the coupon details on
the screen. [Screenshot.]
Pretty simple, and you can read all that in a minute.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974
*** Contribute to the Keitai Developers' Wiki! ***
*** http://www.keitai-dev.net/ ***
Received on Wed Jul 6 01:49:57 2005