Simply put: iCloud should sync email signatures stored in Mail between all of your devices. This one seems so obvious that it’s hard to believe it hasn’t happened yet. Talk about low hanging fruit ripe for picking.
Tag Archives: tech
Samsung’s Benchmark Booster
Anandtech sheds light on Samsung using performance enhancing drugs code (PECs?) to goose their scores in certain benchmarks on the Galaxy S 4.
Artificial Bandwidth Battles
Good article by Jon Brodkin for Ars Technica on what’s happening behind the curtain at your ISP. Perhaps most alarming is the chart on page three showing just 3% of American households had three or more choices for broadband internet access.
iOS Messages Suggestion
The addition of iMessage has been a huge success for Apple, with customers sending billions of iMessages among their iPhones, iPads, iPod Touches and Macs. I’ve read many ways that Apple could improve iMessage; cross ecosystem apps, better group messaging and reliable time stamps across devices, to name a few.
The Messages App itself, though, has seen comparably little improvement since the addition of landscape support. Recently, my spouse inadvertently uncovered an area in need of improvement.
If you have a text or iMessage conversation with multiple numbers for the same contact, it is unclear which is which. So if you message with ‘Jane Work’ and ‘Jane iPhone’ in Messages, you’ll have two threads labeled the as a non-distinctive ‘Jane’.
iOS Messages app should add a quick and visual method to distinguish between two numbers with the same contact. Here are a few suggestions on how this could be accomplished.
One method would be to add the label to the name, so you would see ‘Jane Work’ and ‘Jane iPhone’ in the list view and the conversation view. Another way would be to thread the two. In list view, you would see ‘Jane (2)’ and tapping that would allow you to choose between ‘Work’ and ‘iPhone’, in our example. Lastly, it could be adjusted by color, allowing a user selectable color for any individual conversation in Messages – a popular feature for instant messaging clients.
Any of the above methods would provide a faster and more intuitive way to tell the difference between conversations with different numbers from the same contact.
iOS Mail Suggestion
I never regularly used an email client until 2007. Up until that point, web mail provided the best email experience for my personal email accounts, such as Gmail. I had used several clients in past, including Outlook, Eudora, Lotus Notes and OS X Mail; however, none of them felt easy to use or worth the hassle of set and configuration.
The iPhone changed my relationship with email profoundly: what was once an occasional communications tool suddenly became indispensable. The mobile web interface for Gmail and .Mac at the time was sub par, being optimized for a feature phone WAP browser or altogether non-existent. The Mail app included on the original iPhone removed all of the issues I had with a desktop email client and quickly became my preferred method for reading and composing an email.
The Mail app in iOS has improved quite a lot since 1.0, always proving itself as among the best mobile email clients available. There is, however, one behavior that draws my ire every time I send an email.
When sending an email, the list of suggested or recent recipients starts being shown immediately below when you begin typing in the ‘To:’ field. The intent for this auto-complete feature is to save you time from tapping in a whole address. My problem with this is the inconsistent results it provides. While there are dozens of addresses I have sent email to before, with many more in my contacts, there are two addresses I send more mail to than any other. By far. Why, then, do the auto-complete results change for a given letter? When I type the letter ‘a’, for example, why are the results not the same every time? What algorithm is determining the results and the order they are in?
To improve Mail on iOS, I would very much like to see a method for pinning or tagging an address to the top of the auto-complete list. Either that, or an improved auto-complete that delivers more intelligent, relevant and – above all else – consistent results.
iOS Camera App Suggestion
Apple has a tendency to use the most popular parts, pieces and apps of the jailbreak & developer community to add value to the stock iOS experience. The upcoming iOS 7 does this for example by incorporating a flashlight utility in the new Control Center, instead of the need to acquire a third-party app. This practice was imported from the desktop, where the tradition was known among those developers who had their ideas appropriated as being “Sherlocked.”
I’d like to nominate a category of applications that should be ripe for Sherlocking; bar code scanners. These apps use a devices camera to act as a bar code or QR code scanner, allowing the user to be sent to a website or lookup a products info based on the UPC. A popular example would be Red Laser.
The feature could be added as another mode in the iOS Camera App, and exposed as an API so any developer could have the option of adding the functionality to their camera app. Having the ability to scan 2D codes out of the box would be convenient for end users, and reduce the need to download a single purpose app that is handy yet only occasionally used.
Obviously The Right Idea
Here’s an easy usability tweak that seems obvious to me:
Why not distinguish the left and right sides to a pair of headphones by touch not just sight? The benefit to everyday usability would be felt, quite literally, by everyone who uses them. I assume this could be very useful for persons with a visual handicap as well.
My solution would be to put a small dot or dimple on the right side earpiece, making it easily recognizable by feeling it with your fingers. This would be far more efficient than trying to look for a tiny R or L printed on it, or holding the two up and comparing the shape, or just sticking one in and seeing if it feels right.
Now many modern headphones like the Apple Earpod have a remote and microphone on one side for smartphone use. Why not just let this serve as the indicator between left and right? First, not all headphones have a remote, but all should have a touch based indicator of left and right. Second, by placing the indicator on the earpiece itself the insertion is more efficient and convenient.
So, can we all set the headphone manufacturers of the world down and convince them to collectively implement a universal indicator?
Google Announces Chromecast: Nailed It
About a month ago Benedict Evans shared his ideas about where the Apple TV could go from a hardware standpoint:
Fast forward to today where Google has announced Airplay 2.0 Chromecast:
On the surface, it looks like Chromecast hits the mark:
– $35 price tag
– Plugs into HDMI
– Multiplatform (iOS, Android, Chrome browser)
– Quiet development with release shortly after announcement
But look closer, and some obvious pain points become clear:
– First and foremost, it needs to be plugged in via micro USB cable for power. This ups the complexity and ugliness while reducing the simplicity and portability.
– A router is required for use. Again this reduces the simplicity and portability. Setup remains a question that will have to be answered once it starts shipping.
– Requires third-party developer buy in to implement a new API via the also released Google Cast SDK
– The video stream appears to be an improvised use of a video chat (WebRTC) instead of Miracast, Wireless HDMI or DLNA.
This looks like a solid debut with plenty of excitement from the press. Even though it will launch with limited app support (Youtube & Netflix mostly) you have to start somewhere (Apple with iTunes, Roku with Netflix). I like the idea that once you send something to Chromecast, it takes over the stream leaving the device free to operate or continue browsing for the next video to play. The difficulty in improving a 2.0 product lies in partnerships though; getting developers to implement the API, and getting TV manufacturers to properly support next generation standards such as CEC and MHL, along with deploying WiFi Direct across many products.
My biggest fear for Google is that while they “nailed” the basics in 1.0, the visual of a dangling cord and power adapter the size of the device itself will make Chromecast to easily laugh off with a picture and the sarcastic phrase “Nailed It!”
Overall a big pivot in the livingroom strategy of Google that looks to be in the right direction. As is always the case though, time will tell if Chromecast will overcome the hurdles to success. Early praise and interest is easy for Google hardware, long-term success is more elusive.
Palm Reading
In January 2010, many tablet computers were announced at the Consumer Electronics Show in Las Vegas. Nobody really remembers them, mostly because they either failed to reach the market or failed to sell. This was a pre-emptive strike on the tablet everyone does remember, introduced just days later: the iPad.
Once the iPad started shipping in April 2010, the impact was swift and shredded roadmaps across the industry – including three other key April events:
– Microsoft cancels the Courier project
– HP cancels the Slate tablet announced in partnership with Microsoft at CES
– HP purchases Palm for $1.2 billion
By scaling up its mobile operating system and hardware instead of scaling down their desktop counterparts, Apple immediately superseded years of work by Microsoft and its partners to establish a consumer tablet market. Left flat footed by the rejection of Windows 7 running on Intel Atom processors, Microsoft was at risk of being left behind completely in the tablet market, as HP bought Palm and Dell (and many other PC manufacturers) went with Android. This would seem to be the genesis for what was to become Microsoft Surface with Windows RT Surface RT.
But what if…
Suppose that instead, Microsoft – not HP – had purchased Palm, an idea at least one person, Jason Hiner floated in 2009. First, let’s look at the reasons why this didn’t happen:
– Microsoft was already well into ruining Danger Inc Project Pink (the Kin phones)
– Microsoft already had a nascent tablet UI idea in the Zune/Metro Style
– Palm WebOS had no lineage or compatibility with Windows CE or .NET
– Microsoft was already rebuilding a smartphone OS from scratch: Windows Phone 7
Had Microsoft jettisoned Project Pink earlier, it easily could have re-provisioned those funds into an acquisition of Palm. At the time Palm was acquired, it had the Veer and Pre 3 smartphones in development, as well as the Touchpad tablet. Microsoft could have released the Veer as its feature phone idea, with the Kin social elements on top of WebOS. The Touchpad could have become a development unit for its merging of WebOS and the Metro UI. Here, the card’s UI metaphor in WebOS could have made a lot of sense by calling them instead … Windows. The social information strategy is actually similar between WebOS and WP7; both wanted to combine your various information sources and present a unified interface for communications. Backwards compatibility, as it turns out, is a non-issue, as WinRT has none, and both WP7 and WP8 have broken it as well.
Armed with a well-developed mobile OS, Microsoft could have introduced Metro OS for use on tablets in late 2010/early 2011. This would have brought the manufacturing partners closer, rather than pushing them further away as WP7, Windows 8 and Surface RT have done. This could have led to Windows Phone 8 instead being Metro OS 2.0, now for tablets and phones, featuring app compatibility with established developers, apps and ecosystem.
By allowing HP to purchase Palm instead of acquiring it for themselves, Microsoft let the relationship between itself and many PC and smartphone manufacturers sour, encouraging an “everyone for themselves” survivor mentality. This represents a missed opportunity to quickly bring to market a competent mobile OS that anyone would want to license, rather than everyone fumbling with costly, amateur attempts at vertical integration.
Surface RT Observations
I liked this editorial from Daniel Eran Dilger. Punchy, a little silly but harshly honest. Let’s not forget a couple of additional details I’d like to point out:
– Go big [and then] go home: It seems as if Microsoft is always willing to give a project a billion dollars (Zune, Kin, RT).
– The bizarre naming story of Metro/ WOA/ WinRT/ SurfaceRT. They should have sent a poet marketer…
– Palm Pad / HP acquisition: The number one PC vendor blew its pivot to mobile in a billion dollar acquisition to no where.
– WinRT was supposed to have plenty of apps as developers flocked to redesign apps for the Metro UI, which has yet to happen for Windows 8, let alone RT.
– HP, ASUS, MS all launched iPad competitors that required accessories to be complete “tablet PC” packages as they envisioned, and the cost of a complete experience was always way above iPad, even at $499 (now $329). All were unwilling to sink a few billion dollars into hardware losses to win second place by including the accessories (usually a keyboard) and competing on price and value first.
– Don’t forget all the manufacturing partners that walked away from MS after the Surface announcement; it pissed them off and few produced RT devices.
– The irony that Microsoft could find a profitable niche in content creators; as Apple shifts focus from the creative markets of yesterday, those professionals are increasingly turning to alternatives like HP workstations for work, and the Surface Pro is a well regarded visual artists’ tool. Actually, scratch that, this doesn’t help the case for WinRT anyway.
– A billion here, a billion there, pretty soon we’re talking real money. Microsoft may no longer have the influence, but they do still have the cash (for now) to buy their way into market share significance.
Trapped Speed 