I’ve been excited to try Sparrow on my iPhone since I saw it announced last year. I haven’t been a fan of the desktop app as I’m so hopelessly dependent on MsgFiler with Mail.app to support my email workflow, but I was hoping that Sparrow on the iPhone would be an improvement over the included iOS Mail app (especially if it had some kind of type-to-file support).
So when I saw chatter about it last night, I went ahead and purchased right away. I don’t use GMail, but that shouldn’t be a problem since it has:
Full IMAP support:
Use your Gmail, Google Apps, iCloud, Yahoo, AOL, Mobile Me and custom IMAP accounts.
When I launched the app, this is what I saw:
Ok, that’s not what I need. I need a way to enter in my IMAP server and account details. But this isn’t too uncommon with a mail app. I’ll just enter in my details and wait for it to fail, then it will show me an “advanced” button or something to let me enter the server settings directly.
Hmm, that’s not helpful. I’m not even trying to connect to Gmail.
I tried adding a Gmail account and going into the settings to see if I could adjust the mail server addresses manually from the account settings screen – no can do.
It appears that Sparrow’s only set-up path is to be clever and try to guess at what I need. Like most software with this approach, it fails in real world situations. It may be a great mobile mail app, but if I can’t get it to connect to my account it’s completely useless to me.
Sparrow isn’t the only app that fails like this. The WordPress for iOS app fails in the same way. I believe the WordPress app tries to load an HTML page and look for some specific information (the XMLRPC URL) that it needs for communication (perhaps with a few guesses as well).
If you have a WordPress site that requires a login, your results to add that site to the WordPress iOS app will likely look something like this:
“Need Help?”
No, I need a damn text field!
I’m quite capable of typing in the XMLRPC URL myself (like I’ve done for other apps that post to my WordPress site) and I have no problem with that being an extra, manual step since my WordPress site is a little non-standard. However, that’s not an option.
I grow weary of people holding up Apple as an ideal of simplicity, trying to follow that model, but failing to properly account for real world usage in their clever 
user friendly 
designs. When you place “simple” ahead of “functional”, you’ve failed.
Strange. My server doesn’t match my email as well and when I entered my email in that first screen I had to wait for it to fail, but then was presented with a page to enter all the server/login/password info manually. Worked fine.
+1
Sometimes we have custom setups that don’t abide by the “typical” standards. These apps fail hard when that happens.
That’s very strange. I was able to connect a non-Google account just fine — I was presented with “advanced settings” after Name/Email/Password were entered. Wonder if it has anything to do with your email host.
Alex King: Sparrow for iPhone: Simple Failure: I’ve been excited to try Sparrow on my iPhone since I saw it anno… http://t.co/XFLP7bGS
Alex King: Sparrow for iPhone: Simple Failure http://t.co/Z0uWvxAe
New on @alexkingorg: Sparrow for iPhone: Simple Failure http://t.co/KVtTKNnd
Sorry to hear about your trouble with the WordPress for iOS app.
It looks like you have some pretty hefty security on crowdfavorite, so to be able to access the xmlrpc endpoint, you first have to be logged in – this makes the app break (/xmlrpc.php redirects to wp-login.php). In my mind, you don’t need to block access to the API since it has it’s own authentication, in which case the app should work.
The app guesses your xmlrpc endpoint based on the URL you enter, but if it doesn’t work out it should ask you to put in the full endpoint address.
Hey Isaac!
If it did that, I’d be quite happy to enter it. If it failed at that point, my next step would be to troubleshoot on my end.
We recently moved our internal sites to a multi-site environment which moved the xmlrpc.php file to the root (and the security may have been tweaked at that time); before that (going back to 2007) it was in a subdir and the app appeared not to properly guess the subdir location of the xmlrpc.php file. I’ve never seen the manual entry field, perhaps it could be more accessible?
Also, I filed a bug in trac about this years back (was also about self-signed certs – which appears to have been fixed already?) but perhaps the tickets got purged at some point as I can’t locate the ticket anymore.
There is no special field. You just put the XML-RPC endpoint in the “URL” field.
How should someone know to do this?
Pretty sure I tried this in previous versions and it didn’t work, but glad to hear it if it does now.
The field could definitely be made more accessible – we might as well just not hide it, just say “Advanced” or “Optional”. Should be a simple update. I get your frustration with this, there’s nothing more annoying than not even being given the tools to solve the problem yourself. Ticket added, we may be able to squeeze it in for 2.10: http://ios.trac.word[...]g/ticket/992
As for the ticket you created, I can’t find it either. However, there are a few tickets covering SSL issues and you’ve commented on one of them referring to a forum post. #232 (it’s quite a novel): http://ios.trac.word[...]g/ticket/232
Bottom line: Since 2.7 you should be able to connect to your blog even if you have a self-signed certificate. You should also be able to just enter the full address to the xmlrpc endpoint in the URL field, although admittedly I haven’t tried that too many times myself. Please let us know how this works for you.
Since neither of us can find the ticket I thought I opened, I think the most likely situation is that I must not have actually opened it. Perhaps I had an email exchange with someone, regardless – oops!
I will do some more testing on this in the morning and report back accordingly.
Correction: Apparently there is no field! I was so sure of it. My mind is playing tricks on me.
I believe what I was thinking of was another error message, and/or modifying the label of the URL field to highlight that it’s really for the XML-RPC endpoint. We’ll update the ticket with the findings and map out how best to conquer this usability issue.
Yours is not a problem of XML-RPC discovery. Even if you put the XML-RPC endpoint directly you won’t be able to access it because of the way you have the wp-login redirect.
What we do with the URL:
1. Assume the given url is the home page and XML-RPC sits at /xmlrpc.php
2. Try the given url as an XML-RPC endpoint
3. Fetch the original url and look for the RSD link
4. Try removing “?rsd” from the url, it should point to the XML-RPC endpoint
5. Parse the RSD document
If you have moved your xml-rpc file, there’s a plugin to make the RSD be aware of the change
In your case, changing the plugin redirecting to wp-login to check for XMLRPC_REQUEST first will probably do the trick
That works in this instance, but a single instance is not representative of the entire problem. For example, installation in a subdirectory (which is how this site was previously set up) is not handled through the steps you outline above.
– I’ve been excited to try Sparrow on my iPhone since I saw it announced last year. I haven̵ http://t.co/9Iq7ncOX
I think with the dominance of Apple and others who want to be like it (Google, these days), the world is splitting into two realities: The Simple and The Simple Resistance. Those of us who prefer customization and complexity are finding that our numbers are rapidly dwindling as everyone else – the 95 percent, if you will – are finding that their needs (which aren’t much) are being met with The Simple. Keep resisting. !Viva La Resistance!
I’m not against Simple, I’m against poor app design that doesn’t allow for edge cases. The two are not mutually exclusive.
[?] Sparrow for iPhone: Simple Failure http://t.co/w6mhQ5kD
A bot late but swipe left un that screen allows customization.
Really? Wow, what horrible UX design.