More On That iPod Touch Mystery

Update: New iPhone/iPod Touch WordPress Test This Week

Reader RaminF (formerly Ramin?) left a Comment that pointed to an apparent different CPU clock speed for the iPod Touch versus iPhone: 400Mhz for the iPod Touch versus 620MHz for the iPhone.

Ouch!

Can that be true?

Not being a programmer — just an eejit end user — off the top of my head that looks like it will affect the speed of game play on each unit.

I have to ask: Does Apple itself note this speed difference in the beta iSDK just released?

I posted below that I was going to do another test post from an iPhone.

I tried. But Safari went POOF!

OK, first let me set up the conditions and some specs from these tests.

I was the second person into the Apple Store Soho this morning. I got there a few moments before they actually opened the door.

Yes, I hate a mystery that much.

I ran the speed test pointed to in this Comment and got 771kpbs on an iPod Touch. The speed test noted I wasn’t using an iPhone; does Safari on the Touch send out a different identifier than the iPhone?

I went to Settings->Safari and made sure to scroll down to Clear History, Clear Cookies, and Clear Cache. The iPod Touch was running 1.1.13.

Safari went POOF! on the first attempt. I’d filled in the post Headline field and then tried the Post field when it went south.

I was beginning to get a hint of what was going on here.

I went to an iPhone. Repeated the pre-post steps, including the speed test, which was well over 750kbps. I confirmed that I was on WiFi and not EDGE by asking an Apple Store employee. The iPhone was using 1.1.14.

This time I got the keyboard lag that I described yesterday with the iPod Touch!

Safari then went haywire on me and I had to abort the test.

I went back to the iPod Touch and wanted to see just one more thing.

And now I think I know at least some of what’s going on here. For those who are impatient: the bottom line is that there is some sort of conflict or mismatch between Safari on the iPhone and iPod Touch and the WordPress web interface for posting.

If you want to know more, keep reading as I give an illustrated step-by-step and pinpoint the problem.

This is what I see when I log into my blog:

wordpress0001a2.jpg

This is the important area:

wordpress0001b.jpg

I usually pinch to enlarge that area. You can see that desktop Safari for Windows has highlighted the first field. Neither field is highlighted by Safari on the iPhone and iPod Touch. I must tap in the first one. That tap is recognized as being in a text field and Safari brings up the on-screen keyboard. Logging in here, I have never experienced any keyboard lag.

I then get the main WordPress screen:

wordpress0002a2.jpg

At the upper left are three drop-down menus. If I tap on any of those to try to use them, Safari on the iPhone and iPod Touch somehow interprets that as a page refresh! The menus will not drop down.

This is how I usually enter this blog from a desktop machine, by using the drop-down menu:

wordpress0003a2.jpg

wordpress0003b.jpg

But that doesn’t work on the iPhone or iPod Touch. So have to tap directly on this blog’s hotlink:

wordpress0004a2.jpg

wordpress0004b.jpg

Note that I do not have to pinch-out to enlarge this at all. The accuracy of tap recognition on the iPhone is downright supernatural. I can tap the few-pixels-high hotlink easily. It’s never given me the wrong link!

Then I am at the Dashboard for this blog:

wordpress0005a2.jpg

And it’s from here I choose Write:

wordpress0006a2c.jpg

wordpress0006.jpg

Which gives me the web interface for post entry:

wordpress00072.jpg

Desktop Safari for Windows has highlighted the post Headline field in blue. Safari on the iPhone and iPod Touch does not do that. I have to tap on that field. I can do that without pinching out. As soon as I tap, Safari recognizes it as a text field and gives me the on-screen keyboard. I can type headline text.

Next is where it gets tricky and this is when Safari on the iPhone and iPod Touch tends to go POOF!

wordpress0008a2.jpg

wordpress0008b.jpg

The default here is Visual mode, which lets you see text as if it was a WYSIWYG word processing program.

Two things about this:

1) In default small view, without pinching out to enlarge, Safari on the iPhone and iPod Touch does not recognize this as a text field! I cannot get the on-screen keyboard to pop up.

2) If I pinch out to enlarge it and then tap it, Safari goes POOF!

So what I must do is switch to Code mode:

wordpress0009a2.jpg

wordpress0009b.jpg

I have to pinch out to enlarge that area. Even here it gets tricky:

1) Safari on the iPhone and iPod Touch is very, very fussy about the degree of magnification. Too little, and it will not recognize it as a text field.

2) Even when it is recognized as a text field, if Safari doesn’t like the degree of magnification, there will be a noticeable lag when typing with the on-screen keyboard!

In addition, just like Safari for Windows (and, yes, even Safari on the Mac itself!), blank lines wind up being discarded and text gets all scrunched together.

There is also a problem with trying to check off Categories to place a post in. (I haven’t done a screen snap for this.) The degree of magnification is important because it’s a scrolling field. Sometimes it won’t permit scrolling.

When I did the test posts, I never did Save and Continue Editing. I just hit Publish. I didn’t want to invite more headaches!

To log out of WordPress, once I’m back at the post entry interface, I use the Log Out hotlink at the top right of the screen:

wordpress0010.jpg

And I’m outta there!

When the iPhone came out and people had it, I kept asking around if people could post to WordPress blogs with it. I didn’t get any answer.

I knew I could post to WordPress posts as a Comment, because I’d been able to try for myself.

Every time I tried to log in to my blog, I guess the Apple Store WiFi was so overloaded that I was put last in the queue. It always took far longer than was practical to try, even as a test. This is why I made sure to get to the Apple Store this morning when it opened. Even with full WiFi throughput, it takes quite some time to build the web interface for post entry.

Again reader RaminF:

One reason why the WordPress interface is crapping out might be the giant-ass MCE ‘pseudo-word-processing’ control that WordPress insists on using. It’s around 300K and sucks down a lot of other stuff. If you find a way to turn it off and go to a regular text-box, that might help.

As everyone can see, I’m using the free WordPress blogging service, so I’m stuck with what they offer.

However, it’s already been announced — well, sort of — that WordPress is working on mobile blogging, or at least some peace with Safari (which I hope will include the version on the iPhone and iPod Touch!). See these posts for Safari and WordPress problems:

From my old blog:
Apple Safari Browser For Win XP: Super Fast And Super Sick
Apple Safari Browser For Win XP: Super Fast But Still Super Sick
Safari For Windows: Still Sick!

And posts from other blogs:
Safari 3 and WordPress still don’t want to play nicely together.
Safari 3, WordPress 2, TinyMCE and paragraphs
WordPress and Safari: Will the Fighting Ever End?
Surfin’ WordPress 2.5 with Safari 3

What I really, really look forward to is a front-end application that can be put in an iPhone and iPod Touch that will interface with the free WordPress service. It seems to me that such a thing is available from Google for Blogger (at least that’s the impression I got this morning when I was going through the iPhone and iPod Touch). I’d like to have the same with WordPress.

I hope that the iPod Touch mystery is now solved.

Update: Here’s some info about the WYSIWYG word processor-like web interface WordPress uses — TinyMCE.

Update: New iPhone/iPod Touch WordPress Test This Week

About these ads
Explore posts in the same categories: Tech - Apple, Tech - Other

7 Comments on “More On That iPod Touch Mystery”

  1. Brad Says:

    I run a WordPress blog and have given up using Safari in favour of Firefox because end of lines don’t seem to work.
    Brad

  2. ramin Says:

    (Not sure why the comment post changed my name, but yes, RaminF and Ramin are the same.)

    Very good tips on what could be going on. First of all, the drop-down menu issue. A little background:

    Desktop systems have a mouse and a button. The ‘events’ they send to the operating system are the mouse position and the state of the button (to simplify, let’s call them: none, down, hold/drag, up, or double-click). With AJAX, browsers can now build their own fancy ‘synthesized’ pop-up menus by tapping into these events and do something as soon as an item is selected.

    Doing this requires the software to know the mouse position so it knows what item you’re selecting or highlights things when you hover, and the state of the button (click to open the pop-up, hold down and drag to pick the item, and release to make it happen).

    Trouble is, in the iPod/iPhone interface, you don’t have a mouse. You have a fat finger that occasionally taps a pretty big chunk of screen space instead of a single point. There’s no way to tell where the ‘pointer’ position is going to be until you’ve put your finger down (god-like) and then the system has to quickly decide what exactly you’re ‘clicking’ on.

    In technical terms, the browser never sees a ‘mouse-move’ event until it gets a ‘button down’ event and far more importantly, it can’t tell the difference between you lifting your finger to select something vs merely moving your finger elsewhere! Now Apple’s done a great deal to make iPhone/Safari HTML/CSS compatible. But this Javascript/AJAX business is where the paths split off.

    More importantly, any website that relies on that specific event sequence is going to have trouble with a touch interface. The easy solution is for AJAX toolkit writers to update their software to accommodate touch events (not too hard or them to do, since they can tell that the browser they’re running on is an iPhone/iTouch so they can adjust).

    As for the browser going poof when you start editing, it definitely smells like the problem is with the MCE control. I haven’t checked, but I believe even the ‘code’ entry form is still using the MCE (just in ‘raw’ form). The control is great for letting users edit content without having to learn HTML tags. Unfortunately, it’s also pretty buggy. I’ve always had problems with it, especially with line-breaks, so I had to switch to o a standalone desktop blogging tool (MarsEdit on the Mac).

    The solution is to have an iPhone-friendly interface that can post to WordPress. There is a de-facto standard for submitting posts to blogs (called the MetaWeblog API). So someone could write a little iPhone web-page that takes the content and re-submits it to WordPress using the MetaWeblog API. (I would do it, except that I’m heads-down working on some iPhone apps along with my regular job and a couple of writing projects).

    It shouldn’t be too hard to browbeat someone into doing it ;-) You can wait for WordPress to come out with their native client, or hold off till June when the app store opens. I’ll be surprised if someone doesn’t come up with a native iPhone blogging client and make all this moot.

  3. mikecane Says:

    >>>You have a fat finger that occasionally taps a pretty big chunk of screen space instead of a single point.

    I didn’t mention that I did try pinching-out to enlarge that area as a way of increasing the accuracy of the tap. That didn’t help.

    I think WP itself will have to do the front-end. As you see, I use the free service. There is no ftp to use here (which sounds like something using the MetaWeblog API would require).

    I’ve already stated that dear god I want blogging software for the iPhone:
    http://mikecane.wordpress.com/2007/02/10/reference-mac-os-x-blogging-tools/

    I’m sure others do too and devs are working on it. WP itself better be too!

  4. David Says:

    Maybe I missed the whole point of this but what if you disable visual rich editor in WordPress (go to Options > personal profile) and it is there near the top with a little box, and next to it it says

    “Use the visual rich editor when writing” Uncheck that.

    I have disabled the visual rich editor in my blogs and much easier it is to work with text without the little helper.

  5. billso Says:

    A WordPress interface for iPhones and Touches seems like overkill to me. At best, small devices are good for a short blog entry. The editing interface that WordPress software uses is designed for a VGA or larger screen.

  6. mikecane Says:

    @David: Holy cow. You might be onto something there. But right now I’m tired, my eyes are shot, and my mind is jelly and I can’t find that option. But I do recall it. I’ll have to try that!

    @billso: I don’t see why. I can envision it as a few distinct screens:

    1) Login
    2) Screen with headline and body text fields
    3) Photo/image upload screen (using iP/iPT image picker)
    4) Choose Categories
    5) Preview/Publish
    6) Log Out

    Each screen with that blue arrow-like tab on top to switch through. In fact, with Prefs, #s 1&6 can go away.


  7. [...] More On That iPod Touch Mystery « Mike Cane does some tests, and thinks the iPhone and iPod touch may have processors running at different speeds. (tags: iPod iPhone Apple SDK development) [...]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: