Sunday, September 04, 2011

A Recap On Entering a Post-iDisk World With iCloud.

Or rather, with iWork.com.

Noticed that iWork.com is still going to operate after MobileMe goes down—since iCloud is not going to provide a way to publish data to other iCloud accounts, iWork.com may be the only Apple service available to distribute media to others that you nominate.

Most likely, those photos (and maybe movies) that you send to friends and family may end up as Keynote files that you could publish with iWork.com. You should be able to play back the Keynote presentation in the browser, but it may also be the case that you'll have to download and open the Keynote file on your Mac (or a generated PowerPoint file on a PC) to see the content.

Finicky, but hopefully Apple has something in store to facilitate the idea.


—tonza

Labels: , , ,

Web No Longer Backwards Compatible.

When HTML was devised back in 1993, and evangelised heavily in 1997, the idea was that user agents (Web browsers) should be able to pick and choose the data they could render or present, and ignore the data they couldn't use.

But in recent years in the new century, as developers tie in forgiving HTML and CSS with unforgiving JavaScript (a language with strict object binding rules) and user-agent-dependent DOM, the original goals of HTML are now unrealisable.

As more developers do things like this, and that, and so on, and even as far as this, and for hundreds of other questionable excuses, the Web is becoming more and more reliant on users actually upgrading their user agents, which would most likely mean upgrading their computer systems (in both hardware and software) to cope with the level of compliance that many Web sites demand.

Compatibility and scalability of the Web has been thrown out the window in favour of making Web pages that turn out to behave like on-line applications, and often have a high turnover or rate of change. Surf the web with Internet Explorer versions less than 8, or on a Mac running anything less than or equal to Mac OS 9, Commodore Amiga, an Apple MessagePad, or even an Apple II will be met with a guesstimated 50% of all Web sites unusable due to immensely unforgiving and poorly written mark-up, and reliance on JavaScript.

And in Internet Explorer's case, flat-out refusal to serve.

The Web is no longer delivering on its promise, thanks to Web developers who wouldn't care more for those who are not using whatever the latest and trendiest are from the industry. So as an owner of some old (and expensive at the time) hardware, it's becoming a struggle to keep these machines connected to the Internet and be useful. It's now more sensible to purchase a machine that is powerful and cheap enough for just running your latest version of Chrome, Firefox or Safari, just for surfing around, and leave all your other work for other, more powerful and less dependent computing systems. As for Internet Explorer, you'll need a tablet running Windows 7 for that. And some other tablets may have their own browsers, too, which may have their own compatibility issues, but should mostly be fine to use.

Unfortunately, I can't suggest a tablet computer that uses a mobile operating system for surfing the Web with for other reasons that are uniquely but equally lame as the ones this article describes.

If you think I have been advocating the Apple MacBook Air recently, you'd be well and truly right! I can't find a better system exclusively suited to Web surfing that would last.


—tonza

Labels: , , , , , ,

Counterproductive Mobile Web Sites.

More and more Web sites are pretending to be mobile Web apps when they are not. Worse, these so-called "mobile" sites often provide limited functionality compared to what would otherwise be delivered for PCs (and Macs).

Meanwhile, mobile Web browsers, such as MobileSafari for iOS, or Chrome for Android, are capable of fully supporting and easily interacting with those Web sites that appear on PCs. However, Web site developers instead make sites that cripple the browsers' capabilities and perform less functions on mobile platforms, in an attempt to make things appear to work better on your mobile device.

And that leaves visitors in a disadvantage, because people who visit sites with mobile devices, including iPad, will not be able to see or do what they could otherwise do on their PCs, making these devices not so useful for surfing the Web with, and undoing all of the hard work that mobile operating systems vendors put in to making mobile devices work in a ubiquitous world.

When Apple decided to extend iPhone OS (as it was called then) using Web Apps, the intent was for developers to make applications for iPhone using Web technologies but are deployed as icons that are downloaded from the Web and are launched from SpringBoard (the Home screen in iPhone OS) by tapping on its icon after it is installed. However, many developers bypass this feature entirely and make a half-baked solution by just concentrating on making the Web sites that are accessible through MobileSafari instead of developing them as the Web Apps that Apple initially proposed.

While these sites would have the same features as Web App versions of the same thing, the sites impose two limitations than what Web Apps are expected to be:

  • users know that they are launched through MobileSafari and still appear as a Web site rather than have the appearance and behaviour of a Web App, and
  • these sites often override full-featured versions intended for PCs because the sites are designed to only feature the "mobile" version of the site to MobileSafari users, thus preventing MobileSafari from offering regular browser features for users who expect to zoom, resize, scroll, select and otherwise interact with the Web site like any other for desktop PCs.

There is currently no way for user agents such as MobileSafari to tell Web servers to appear as peer versions that run on PCs, thus there is no way to convince Web sites to provide full content versions despite the fact that the browser can actually deal with them!

I can think of a few sites that annoy the living daylights out of me in this regard:

  • Nintendo Australia show a "mobile" version of its site, and does not allow iPhone users access to the full-featured version. The mobile version of the site is so cut-down that it's not worth visiting unless you want to read about press releases from the company.
  • Twitter have forced their consistent user interface conventions with their "Twitter Mobile App" look, feel and function onto iPhone users, to the point where users cannot perform some rather important administrative procedures, such as edit their own profiles, from their mobile device. To edit their Twitter account profile, users now need to use a PC! Not even an iPad can help out here!
  • In the same manner as Twitter, other popular communications and social networking services from Google, Yahoo! and Facebook all have reduced their services to the point where only some functions are available to users from their mobile phone.

With all these limitations being imposed on mobile users, there's much less sense in using gadgets like an iPad—you may as well get yourself a MacBook Air instead since they appear to the world as Macs, and Web site developers haven't crippled their sites for that user base yet.

(Users of Web OS and Android may have a different experience here... I shan't comment on those since I'm not familiar with them.)

If you want a Windows-based PC rather than a Mac, that's OK, but I'm just not familiar with what mobile options you'd have in this regard... except that you'll want to run a "desktop" Windows environment rather than a "mobile" one.

Web site developers need to understand mobile platforms are much more capable than what they are giving them credit for. All too often, there are times where I'd like to visit their "full" site with my phone, but am not able to because access to them have been denied at the Web server. I am not pleased at all in their decision to do this.

There is no harm in making tools that are more suitable for use on mobile phones... on an iPhone, there is a way to do this without sacrificing the utility of MobileSafari for what should be ubiquitous Web surfing. It's just that Web developers are just not making it happen sensibly.

Also, Apple could provide a switch in MobileSafari so that it can pose as a Mac or PC version of Safari for those times where Web sites are being too selective or abusive for no good reason.


—tonza

Labels: , , , , ,

Computers Now Require a Network To Operate.

Have you ever tried running applications on your computer with the network disconnected? Applications on the Mac are starting to malfunction (hang) when a network connection to the outside world cannot be established, particularly:

(Sorry to pick on you, James! But to be fair, your excellent DragThing 5 doesn't have the same problem as PCalc does.)

Applications on the Mac that rely on communicating to MobileMe services, such as iPhoto and iMovie, or just ping out to the Internet just for the sake of update discovery, such as PCalc, are starting to misbehave as developers no longer consider that computers should still function even if they are not connected to a network. And what I fear is that as more developers use iOS as their platform for starting off some of their brilliant ideas, they soon forget what life is like without a network, particularly on older computers that do not have wireless interfaces as standard. And if and when those skills transcribe to Mac software, users will be at the mercy of developers who don't actually test their software in computers without any network connections!

Of particular worry are applications that "phone home" to check on whether they need an update before they actually start doing the work they are designed to do. EyeTV checks for updates to itself before it opens up its video window. PCalc checks for updates to itself before it allows the calculator window to be useful (because the window is left inactive whilst this check is in progress). And there a lot more applications doing this than I can count. I would argue that this is the wrong thing to do—applications should not go checking for updates to themselves before they start, because, chances are, users want to use their applications when they start them, regardless of what version they are! But more importantly, secondly, when applications do check for updates should be at times of least inconvenience, such as at times when an application is idle, for example. And thirdly, these checks should not be accompanied with dialogue boxes and windows that prevent the application's user interfaces from being blocked. And lastly... before applications go check for updates, they should check that they actually have a network connection, without first trying to access a DNS service! Checking for DNS services is difficult because it ensues that the process may be rather lengthly whilst the application hangs and waits for a timeout (which is avoidable as multi-threaded processes), but checking for an active network interface first is much easier and poses the least disruption to its operation rather than going for broke and failing badly.

If users are having trouble using applications when they are running on computers that are not connected to a network, they should let their developers know, because this is a bug, plain and simple. And it's a bug that should never be allowed to survive, regardless of how pervasive the Internet is in today's computing environments.

I predict that in the future, if this assumption is continued to be practised in new software developments, personal computers will no longer be usable, let alone useful, without a network connection, as developers' software forget to be considerate on how to behave when this critical resource goes missing. And this is thanks to the fact that software development on hand-held computers and laptops may accidentally obfuscate a discipline in testing for the presence of a network since mobile apps expect to be connected to at least one. Once these sorts of tests cease to be of interest in product testing, practices and code that could make it to desktop applications from a mobile application development project are going to cause much needless pain and suffering to end users as this sort of software development issue becomes more prevalent as accessibility to networks become the norm in computing rather than the exception.


—tonza

Labels: ,

Entering a Post-iDisk World With iCloud.

Now before I start, I know that I could look for alternatives to iCloud , but I won't do this here. The aim is to compare how iCloud uses a Mac's local storage with how MobileMe services uses iDisk.

With iDisk leaving the cloud next year, what would iCloud offer that is synonymous with what iDisk used to offer?

Taking a look at some of the lightweight MobileMe services—BCC syncing, Find My iPhone—iCloud would be able to, and has been announced that it will, continue to operate as it did with MobileMe, albeit without a notion of an iDisk. Instinctively, these features do not require globs of mass storage at Apple's end to implement, so there is no need to observe a remote filesystem which stores the data required for these MobileMe services to exploit.

However, the remaining MobileMe features, such as MobileMe Mail, MobileMe Gallery and iWeb hosting all require mass storage to hold your mails, your photos and your Web pages, and this is all exposed to users as iDisk. Interestingly, the use of iDisk amongst these three services have been integrated somewhat, so that media incorporated in incoming e-mails and in Web pages are kept at the same place, as is media presented by MobileMe Gallery.

Thus, without iDisk, iWeb hosting and Gallery are no longer in iCloud. It is surprising that MobileMe Mail will continue to be offered as a service, since this will require some storage in order to store people's e-mails, so while iDisk will not be offered as an iCloud service, some remote storage capacity will still be there.

One service that hasn't been mentioned yet is Backup. It first appeared in .Mac, where it was possible to use iDisk to remotely store people's files as backup archives. This is going to be lost, too, once iDisk disappears, but it is expected that, as long as Backup's preferences are themselves backed up, Backup can still be used to back up files to local storage. To replace it, though, is iCloud Backup, which may be used to back up iOS devices and user documents. (Question: does iCloud Backup be used to remotely back up documents from Mac OS X applications, too?)

So iCloud is not interested in publishing people's media—your better bet is Flickr! and YouTube. With Gallery and iWeb hosting disappearing, ways to show people your photos and movies from on the Web are to disappear. Photo Streaming, the remaining new capability of iCloud, appears to operate only between registered devices, so it is no good for showing people your movies and pictures from on the Web.

The iCloud Photo Streaming copy on Apple's Web site says:

"Your photos everywhere. In a flash.

Take a photo on an iOS device or import a photo from your digital camera to your computer, and iCloud automatically sends a copy of the photo over any available Wi-Fi network (or Ethernet) to the Photos app on your iOS devices, iPhoto on your Mac, the Pictures Library on your PC, and the Photo Stream album on your Apple TV. So you can show off your shots to friends and family from whichever device you’re using at the time."

So, how are friends and family going to see your photos (what, no movies?!) without you giving them your devices?! Is this going to be useful to people at all, particularly if you want to show them, who may be much farther away than the length of your arm, your pictures? I don't think Photo Sharing is going to be as useful as Apple thinks.

The MobileMe iWeb hosting feature of iDisk could have been used to work around that problem, but Gallery already did this for you, and both features are about to disappear. A third-party solution will have to be sought in order to publish your movies and photos.

I think while iCloud takes two steps forward, it also takes one step back. iCloud would benefit people who have more than one iOS device in the household, and want to entertain oneselves. For sharing with friends or family, iCloud is not going to serve these needs.

Update: As of March, 2012, iCloud has introduced Shared Photo Streams as a feature for publishing users' existing photo streams to others. It does this using iCloud services and publishing URLs to them, so the longevity of the media you publish may be limited, given how Photo Stream works.

While this may resolve some issues with sharing photos to people, it is not applicable to movies, and it is not permanent. You'll still have to use other services if you have the need to present movies or pictures to people on a more permanent basis.

Last updated: 17th November, 2012; mentioned the availability of Shared Photo Streams in iCloud.


—tonza

Labels: , , , , , , ,

Saturday, September 03, 2011

Daring Fireball's iMessage.

In Daring Fireball's article about iMessage, John Gruber says:

"It also means iPhone users with iPhone-using friends and family no longer need SMS. I’ll cancel my SMS plan as soon as this ships."

More like it means that iPad users, for the first time, can actually send other iOS users text messages! (As MacRumors suggests.)

Question is, are Mac users includable in their conversations, or will they still need a steel can and string? No word yet if iMessage will be included in iChat for OS X Lion as well, and I would be surprised if it makes an appearance there since, well, Apple hasn't mentioned it.

Article last updated on 3rd September: It looks like Apple do have a Messages beta-release for OS X Lion (which expired on the 13th of June), and will be integral to Mountain Lion. Nice!


—tonza

Labels: ,

Asking For Administrator Passwords.

One of these days I should make a bug report to Apple about how Mac OS X asks for administrator passwords... I have come up with this idea before, but I don't think I have made a bug report of it before.

The problem is that the Mac tells what process wants the password, but there is never a reason presented for why it wants it. I think developers need to provide the operating system with a reason to report to users before the system should allow the developers' software to obtain an administrator password. This will enable users to decide whether or not to give the system administrator access.

But of course, the operating system cannot verify these messages to users without some hefty artificial intelligence and expensive analysis before using that data, so they cannot deal with issues where applications lie about the reasons for asking for administrator passwords. While operating systems cannot tell when an application presents inaccurate user messages (ie., lies) for users to reason with, users may pick up on other cues to assist in trusting the applications, such as when and in what context a dialogue appears asking for administrator passwords, or that the inaccurate messages presented are too unbelievable to be reliable. In either case, relying on human intelligence to trust or not to trust an application for elevated privileges is nothing more than a game of Russian Roulette, with possibly disastrous results.

This is a difficult problem to solve because it becomes an experiment in social engineering that is not guaranteed to be successful, and so why burden programmers with the responsibility of providing data that cannot be tested by the system before delivering it to users?

Because it is more likely that responsible programmers will provide helpful messages to users in addressing this concern. Programmers that don't provide the messages or are discovered to lie about the reasons for elevated privileges are causes for users not trusting their software, reducing the reputation of the products used. And that's reason enough for all programmers to have this burden.


—tonza

Labels:

Move Along...

This story is rather old, but still well worth telling. It was originally written on the 2nd of May, 2011.

In yesterday's debugging of iTunes authorisation difficulties, I almost missed the following rather hilarious console log:

30/04/11 8:51:19 PM	usbmuxd[4234]
    _MobileDeviceConnect_locked (thread 0xb0081000): This is not the
    droid you're looking for (is actually com.apple.mobile.restored).
    Move along, move along.

Someone is definitely a Star Wars fanatic at Apple!


—tonza

Labels: ,

I Have a White iPhone!

This story is rather old, but still well worth telling. It was originally written on the 1st of May, 2011.

Well, I actually have two white iPhones; a new iPhone 4, and my predecessor, an iPhone 3G. When I actually got the new toy to replace the old one, I was rudely encumbered when I tried to erase and reinstate the iPhone 3G, which failed because it would not be re-authorised by the iTunes Store for some reason.

Turns out that it wasn't the Store at all: instead, Console showed that iTunes itself was to blame for the failure. Console logs along the lines of:

30/04/11 8:54:48 PM	AppleMobileDeviceHelper[4520]
     _MobileDeviceConnect_locked
     (thread 0xa044f540): Could not connect to lockdown port on device
     7d97265988faee1ece1562766256766c4d411af6.
showed that iTunes 10.2.2 was unable to connect to an iPhone 3G upgraded to iOS 4 firmware!

The solution was to install an older version of iTunes that coincided with the release of iOS 4... that is 10.1. It turns out that I was incredibly lucky here since I did have a copy of iTunes 10.1.1 handy—because, if I didn't, the poor iPhone would have been stuck in recovery mode forever more, and I would be one sorry idiot.

Apple do not make any version of iTunes 10.1 available anywhere in their support channels, so I sent them a letter to voice my discontent at their attitude towards assisting people in posession of older products:

"I have reinitialised an iPhone 3G because I want to create a new identity (device name, preferences, etc.) for it, since I have transferred its existing identity to a new iPhone 4. However, I cannot reactivate the iPhone 3G now because the Apple Store responds with an error "We could not complete your iTunes Store request. The host is down."

Could you please investigate this because with the iPhone 3G reinitialised, the phone is now waiting to connect to iTunes to complete the activation process, but the iTunes Store refuses to service it.

This is preventing the iPhone 3G from being useful anymore! Any assistance would be muchly appreciated, and could you please regard this as an urgent matter that needs addressing. Many thanks, and kind regards."

Whether that letter happens to do anything would be miraculous! But Apple's policy of not allowing access to all versions of iTunes is not helping people support their own machines.

Meanwhile, the iPhone 3G has been reborn, is alive and well, and now serves a new owner.


—tonza

Labels: ,