njr 3.0

In my previous post I discussed the Web UIs of three newish feed readers. Of these, The Old Reader, as a spare-time project, has a nicely mobile-adaptive Web app and an API in development but no iOS app. Feed Wrangler and Feedly have “official” iOS apps which display natively on both iPad and iPhone/iPod touch. These apps are quite different from one another, thus less amenable to bulleted lists than their Web counterparts.

Feed Wrangler

Feed Wrangler is very much a “classic” iOS app with card-stack navigation and a toolbar at the bottom of the screen. I don’t really mind this as I’ve been using the similarly-organized iPhone NetNewsWire for years. Everything works as you’d expect, with a minor conceit of the “Edit” button being labeled “Wrangle”. Article lists and article views are clearly presented, thankfully without gratuitous extra space as in the Web app. You move between articles with arrow buttons, though I wish the down-arrow were a bit further from the edge of the screen on iPhone (as this is the most common action you’ll perform, it makes sense to make the button bigger). Controls for starring, marking unread (still missing in NetNewsWire iPhone!), sending to Instapaper and sharing—including support for Chrome, Netbot and Drafts—are all obvious and well implemented.

There are no folders/collections/tags for feeds, a feature deficit in the Web app as well. I sometimes want to read only a subset of my feeds when I’m running behind (e.g., professional or frivolous stuff), which this would not allow me to do. There’s no display of the number of items in each category (unread, etc.), which seems like an obvious omission.

The login screen has a 1Password button which launches the app with a search for “feedwrangler”, a very nice touch. Feed Wrangler synchronized my Instapaper credentials from the Web site; my Pinboard API token was either not synchronized or just doesn’t show up.

The built-in browser is usable, but doesn’t display the page title and displays progress in a weird place, uncomfortably close to the reload button (which doesn’t change between stop and reload like you’d expect; example). If you tap on another article in the list on iPad while the browser is frontmost, the article highlights but nothing else happens; this should be better handled (example).

There’s a weird glitch where the article list scrolls slightly before displaying the related article. This happens in both iPhone and iPad versions.

Feed Wrangler has decent offline support, similar to NetNewsWire; images are not cached, however. You see a simple “Failed to Connect” overlay and your changes resynchronize once you have an Internet connection again.

Feedly

Feedly uses custom, minimalistic, gesture–centric 2D UI for its feed and article lists, but standard iOS controls for settings. Displaying an article, you can swipe up to return to the article list (equivalent to tapping the back button), or swipe left or right to navigate between articles (no corresponding buttons). The settings are a bit too generic, for example not providing font previews.

Article lists are presented as a horizontally or vertically scrolling series of list “cards”; I don’t really see the point of this, and would prefer a regular scrolling list instead. In fact, swiping down (or right, depending on your setting) with a scrolling gesture marks articles as read (an individual article or, with a larger gesture, the entire card’s worth); thankfully swiping up marks them as unread. The feed list sidebar uses comically huge headings which, again, seem rather pointless provide enormous tap targets.

Articles do get a toolbar with a back arrow and sharing controls, but without the standard iOS sharing behavior as Feed Wrangler employs. Instead, tapping an Android-like vertical ellipsis pops up an overlay full of mystery meat icons. If you hold your finger on one of the icons for a couple seconds, you do get a “hint” in the iOS title bar (example).

The built-in browser has a “Remove clutter” button — with an inscrutable icon that reminds me more of a highlighter — but no dedicated back, forward, stop or reload buttons. The top-of-screen back button works to go back a page in the browser, but then you need to step all the way back through your history to get back to the article display — or you can swipe up once you’ve scrolled to the bottom of the Web page (or PDF) you’re displaying to get back to the article list.

Feedly has no offline support at all; instead you see this.

Conclusion

As you might have guessed from the above, while I slightly preferred Feedly’s Web app to the other alternatives I evaluated, I did not like its mobile app, which is let down most by its built-in browser and lack of offline support. Feedly implements the Google Reader API, so I’ll keep looking for other apps to try.

10:39 PM | Computing, Web
1 Comment

It’s time to pick a Google Reader replacement. My feed-reading setup for the past few years has been the Google Reader Web UI on desktop and iPad; NetNewsWire on iPhone. On the desktop, I currently read entirely from the keyboard and in Google Reader’s full-screen mode, which hides the sidebar, and in “list” (vs expanded) view. The result looks like this. Keyboard commands I use frequently are:

• space/shift-space to scroll, or check for new articles at the end of the list
• return to toggle expansion
• j/k to move between articles
• m to mark read/unread
• v to open article in new tab
• =/– to change text magnification for only the current article (example, very useful).
• e to email an item
• ⌘4 (on my Safari bookmarks bar) to add to Instapaper

For anyone else who has put off their choice as long as I have, here are some notes on the services I’ve tried. They’re all pretty good, which probably says something about the influence of Reader.

The Old Reader:

• Very responsive.
• Nice UI layout — buttons look like buttons but aren’t too prominent; color is used intelligently.
• Good keyboard support, though some inconsistencies with Google Reader (toggle expansion with x rather than return).
• b to open in background tab (Chrome, Safari, Opera) is useful.
• Can’t hide the sidebar.
• Unread indicator is only a green vertical bar and the article title doesn’t change to/from bold, though I think I could get used to this.
• My favorite article display (example) — adequate width for text, no excessive whitespace or button clutter.
• Only Pocket support (which I don’t use), no Instapaper or Pinboard.
• Search support.

Feed Wrangler:

• Mediocre keyboard support — doesn’t intercept return or space.
• Items remain expanded once you’ve read and moved off them.
• Can’t hide the sidebar or wide margins — not well suited for full-text feeds (example).
• Slow and unresponsive at times.
• Instapaper and Pinboard support.
• Search support.

Feedly:

• Clean UI gets out of your way (if a bit lower density than I would prefer); apes Google Reader most obviously of any of these options.
• Response time is OK but somewhat inconsistent and variable.
• Buttons at the top right of the page are not terribly obvious and require you wait for the tooltips to appear.
• Wide left margin when reading articles; not great for full-text feeds (example).
• Can’t start reading from the keyboard via return or space. j works, though.
• Good keyboard support, including toggling expansion via return key.
• No obvious response to hitting the m key (mark as unread) when an article is expanded, other than updating the unread count.
• No search support.

At the moment, I think I will go with Feedly. The Old Reader has relatively little to do (hiding the sidebar) for me to switch to it. I discuss mobile support for these readers in another post. 

9:30 AM | Computing, Web
No Comments

It’s been over two years since I posted here and I just wanted to assure you, dear reader, that I’m still alive. You can see some more frequent signs of life on my Twitter feed. Mostly I complain about computers, though the majority of my life is taken up by medical school these days.

To avoid this being an entirely content free post, I will discuss something I’ve got a lot of experience with but never wrote about: Bluetooth headsets. I listen to podcasts almost exclusively through Bluetooth headsets, and have for about the past three years.  I wear a headset for probably an average of an hour a day, sometimes more like three or four on the weekends when I’m cooking, cleaning and doing laundry. My right ear is stretched compared with my left ear as a result. I almost never talk on the phone with my headsets, so if you’re looking for a comparison of call quality, look somewhere else.

I have, over the years, owned 6 mono headsets and 4 stereo headsets, not counting the Plantronics headset I got for my father. While most are so bad they don’t bear mentioning, my favorites have been the Jawbone ICON and ERA. I bought the ICON in June 2010; it worked perfectly reliably until I accidentally washed it in September 2011. Newly clean, the LED still came on to indicate the battery was charging, but it never showed as fully charged and wouldn’t power on any more—I don’t blame it! I bought an ERA shortly thereafter, which worked fine until about a week ago when the volume started spontaneously dropping. I think this is simply a loose connection to the speaker as I can often restore the volume by changing the headset’s position. The headset took quite a lot of abuse including several drops so, again, I don’t really blame its design or manufacture. Earlier this week, instead of getting another ERA (left), I bought a BlueAnt Q3 (right), which I haven’t decided to send back yet.

I thought about making a comparison table, but then I realized how much I hate comparison tables, so here are some bulleted lists instead.

Things I really liked about the Jawbone ICON and ERA:

• A2DP support. Without this, it’d be pretty useless for listening to podcasts.
• The power switch is a slider (the extent of my hatred for the Apple aluminum Bluetooth keyboard power button is not printable in this forum).
• The status LED is on the inside of the headset, and is a ring of moderate brightness rather than a pinpoint of extreme brightness.
• Jawbone includes a wonderful shape-holding micro USB cable for recharging. For a while, it was infuriating to try to connect the device to the cable by feel given the odd angle at which it sits, but I eventually realized that the curve on the cable more or less matches the curve on the inside of the headset, and all was well.
• The headset only has one button, whose function is relatively easy to determine: one tap either performs call control functions (if the phone is ringing/off hook) or speaks the approximate remaining talk time. Holding it triggers Siri, if nothing is playing, or cycles the volume if something is.
• Mac software lets me do things including renaming the headset, upgrading firmware, configuring the button behavior, and installing experimental features like (originally) A2DP support.
• You can monitor battery life from the iPhone display.
• The device shows essentially no wear after heavy use for years, aside from the JAWBONE text rubbing off slightly.
• Charging status is easy to see: red pulsing ring for charging, white for charged.

Things I found useless or annoying on the Jawbone ICON and ERA:

• There’s no audible feedback for the first few seconds when turning on the headset. Startup is slow — total time from power on to pairing with an iPhone 4S is about 5 seconds.
• About once a month, the headset would power on, far away from any computer or USB port, and decide that it was waiting for a software update. The headset would feel the need to remind me of this mantra (“Please wait while new software is being installed. Your headset will restart when it’s done.”) every few seconds for a minute. This would play over the top of any audio. There was no way that I could find to abort this process and, you know, use the headset immediately.
• Volume control requires you to hold down the button while audio is playing (otherwise, it triggers Siri, the way I have it configured), and inevitably causes me to overcorrect and/or trigger Siri.  It’s hard to figure out whether the volume is increasing or decreasing, as it alternates after it “bounces” off the extrema.
• Related to the above: triggering Siri requires holding down the button, hearing 2 beeps from the headset, then waiting a while before hearing Siri’s acknowledgement.
• You’re supposed to be able to trigger various actions by tapping or shaking the headset. These never worked reliably for me.
• I have to carry around two earbuds: one is comfortable to wear for hours when listening to audio, but it puts the headset so far away from my mouth that the phone call quality — or, more relevantly for me, Siri — is essentially unusable. The other earbud I use for phone calls, very infrequently. There’s also an ear hook, but it does not attach securely and has been awkward to the point of uselessness in my experience.
• Sometimes A2DP would drop until I power cycled the headset, though the phone would think it’s playing. This may very well be Apple’s bug, as iOS Bluetooth has certainly had its share.

The BlueAnt Q3 shares quite a few of the Jawbone headsets’ features (A2DP, iPhone-visible battery life, power slider) and will hopefully be an adequate replacement.

Things I like better about the BlueAnt Q3, thus far:

• Startup and connection is substantially faster: under three seconds versus 5 for the ERA. Audible feedback on startup is a battery report (unfortunately just as a level like “high”), rather than a chime, and is essentially immediate.
• A2DP is supported when two devices are connected simultaneously. The Jawbone ERA will connect to two devices at once, but only the first-connected device streams audio to the headset. The Q3 announces “There are two phones connected” when the second device connects.
• While fewer earbuds are supplied, and none are designed to sit inside your ear canal (unlike on the ERA), the smaller-size, simpler-design earbud fits me pretty well and — crucially — still allows me to use Siri with good accuracy. No more adding surreal shopping list items while I’m cooking! There’s an ear hook that attaches securely and works well unless I’m deliberately shaking my head (in which case the earpiece moves, but doesn’t fall off).
• Incoming calls play the caller’s name through the headset, rather than just the phone number. I believe synthesized names are synced from your phone via PBAP.
• Volume control is a 1D slider (self-centering, like a joystick) which works whether or not audio is playing. If no audio is playing, you get feedback via audio clips such as “Volume up” or “Minimum volume”. Beeps indicate the extremes of volume if audio is playing.
• There’s still only one button, excepting the volume control, and absolutely nothing requires you to hold it down.¹ You either tap once and say one of a small set of voice commands to the headset (report on both headset and iPhone battery life, pairing, redial, etc.), or tap twice to trigger Siri.
• There are more thorough and well-designed voice prompts; for example, on an incoming call, there’s help on what buttons to push to answer or ignore it, carefully timed so it doesn’t bother you if you know what to do. Audio pairing help is extensive, unobtrusive and well-done.
• It’s possible to trigger a connection attempt from the headset (tap the button and say “Am I connected?”), a wonderful thing if you’re using iOS with its obnoxious refusal to provide fast access to Bluetooth settings.

Things the BlueAnt Q3 doesn’t have, or which I find worse than on the Jawbone ERA:

• There’s an annoying click at the end of each voice prompt audio clip, perhaps when the speaker is getting power cycled. This should really be eliminated.
• One of the voice prompts is just wrong. “Your BlueHead headset is connected.”
• I get a loud noise in my ear, probably from compression of the earbud, when I try to push the button if I don’t hold the headset still with my hand.
• The button offers too much resistance to pressure, feels flimsier, and is oriented vertically rather than horizontally.
• There is no Mac software or ability to rename the headset (“BlueAnt Q3 V1.35”), though a firmware upgrade tool is coming.
• Obnoxious flashing LED is obnoxious — bright, and on the outside. At least I don’t have to see it.
• The grille (decorative?) is already getting things stuck to it after an hour — bad design.
• It comes with an ordinary micro-USB cable, and the headset is difficult to connect to it by feel. It’s possible to use the Jawbone cable, but you don’t end up with a very secure fit.
• The range and interference robustness are substantially worse — not usually an issue when I have the phone in my pocket. I should quantify this at some point.

Some comparative photos I took are here.

For further information, I find iLounge’s reviews to be consistently accurate (Q3 and ERA). There is an iPhone 5-specific issue — related to wideband audio, and looking like Apple’s fault — with the Q3, which is discussed in the review and acknowledged on BlueAnt’s Web site. There’s now a special version of firmware 1.41 to work around the issue. As discussed above, a Mac updater is not yet available (it’s promised for a few months hence) but the Windows updater worked fine in VMware Fusion.

¹Actually, a few features do require holding the button and/or volume slider, but I would never use them daily as I would with Siri on the Jawbone ERA. One swaps the behavior of volume up/down so it makes sense in your left ear, some others handle call waiting/conferencing, and one resets the headset.

6:27 PM | Administrivia, Computing
5 Comments

Finally moved everything off PBXes today. (Of course, I can’t delete the PBXes account until it expires.) I feel quite a bit better to no longer be trusting my phone service to a company like that.

I replaced it with Yate and FreeSentral running on a VPS. I can’t say setting up Yate was easy or the documentation was great, but the software seems robust and I like the architecture. Particularly, I was impressed that I was able to use FreeSentral where it worked, but able to override routing where needed without modifying FreeSentral.

A Yate troubleshooting tip: run with -vvvvv and read the entire log file. Just because something appears to fail in a particular place doesn’t mean it has (i.e, that you’re reading the log correctly), or that the failure was at that place. It could have been much earlier, such as during module loading. Knowing this would have saved me many a wasted hour.

10:42 PM | Computing
2 Comments

Since my posts to their forum keep getting deleted, I’ll post here.

Here’s what happened:

August 10: I created a free account (nriley).

August 12: Happy with the service, I created another free account for my father (griley).

Because I liked the service so much, I decided to upgrade to a paid service—supporting automatic failover and more features.

August 27: I created an account the two of us could share (riley) and attempted to upgrade it to paid, after which I planned on deleting the individual accounts, so there was no interruption in service. Despite this thread, which makes it pretty clear their customers are asking for additional payment providers, the only choice is PayPal.

Only after attempting to pay via PayPal, I got an email that PBXes required my PayPal account be verified (that is, linked with a bank account). I’ve never had any other payee require I have a verified PayPal account, but I imagine they’ve had their share of fraud, so I understood. I don’t trust PayPal with my primary bank account information, so I ended up using a separate bank account for the purpose. This took a few weeks as I had to get the bank account set up for online access so I could observe the PayPal deposits.

While PBXes ordinarily provides absolutely no way to contact them without paying them money (via PayPal) first, PayPal does require a contact email address be included in the transaction receipt; I emailed this address asking about other payment methods, but received no response.

Over the intervening weeks, PBXes “discovered” that I had multiple accounts created and began to automatically disable them for TOS violations.

• August 31: Received an email that griley would be disabled (same name/email/postal address as riley).
• September 1: Received an email that riley would be disabled.
• October 1: Received an email that nriley would be disabled (different name/email/postal address from griley and riley).

Keep in mind the riley account had never been used (except for my abortive attempt to pay for it). The original two accounts, nriley and griley were in use by two different people (myself and my father) so they didn’t violate the TOS at all. If I really wanted to violate the TOS, do you think I would have used the exact same, valid name and address information!?

Here’s what the account blocking email looks like:

we noticed that you created more than one account at PBXes.                     
That is welcome but also creates considerable load on our servers.              
Better would be to stay under a single account as written in our                
Terms of Service.                                                               
                                                                                
You can delete or upgrade the additional account                                
                                                                                
riley                                                                           
                                                                                
to paid within the next 5 days. Otherwise we are going to disable it.           
Thanks for your cooperation.                                                    

What is not clear from this are some properties of a “disabled” account:

• If you try to call a phone number associated with this disabled account from another PBXes account, the call does not go through, even if the call would not ordinarily be routed through PBXes.
• You can’t reuse any SIP trunk associated with this disabled account in another account.
• You can’t view or edit any settings associated with the disabled account to remove this trunk or copy the information to another account.
• You can’t even delete the account.

So, not only was my father’s account blocked, but I was unable to call his phone number from my PBXes account.

Eventually I got the bank account added to PayPal, and the shared account paid for, then PBXes had its own verification which took a further few days, which thankfully happened in time for me to cancel nriley and move over to riley without any interruption in service. My father had no such luck; as you can see above, he was without phone service for nearly a month.

After getting the paid account set up, I made three requests via messages on PBXes’ forum (since there was no other way to contact PBXes short of paying for support, and several other similar account-related messages were responded to, for example this one).

• On Friday, I asked if my father’s account could be unblocked so I could copy the settings out of it. This post was initially locked to replies without a response, but remained in the forum.
• Today, I asked if my father’s account could be deleted so the trunk could be accessible to my account. This post was deleted without a response several minutes later.
• Finally, I posted a longer version of the second post, which made it clearer my purpose was simply to make use of the account I had already paid for, as well as including conciliatory statements such as “I’m not trying to make any trouble” and expressing my frustration about the hoops I had to jump through. This post was deleted immediately, then shortly thereafter Friday’s post was deleted too with no relevant explanation.

So, my only choice was to pay for an account I did not intend to use, just for the “privilege” of deleting it.

Note at no point in this saga have I been personally addressed by any representative of PBXes/i-p-tel; just sent automated messages and left to wonder about their motivations, which at this point seem at best bizarre; at worst, malicious, bullying and extortionate (you must pay us more money to use an account you have already paid for). Certainly, it’s their company and their right, but I’d never treat a customer like this in my life.

All I can do is recommend other people stay far, far away from PBXes’ service. Of course, PBXes doesn’t offer refunds, so I’ve got to pay for a year of their service regardless, plus a month of service on griley just so I can delete the associated trunk.

4:17 PM | Computing
5 Comments