Encouraging Technological Fragmentation

On May 15th the US government issued an executive order that could effectively reshape the technology that many of us will use in the coming decade. Chinese companies are being accused of using their position as the world's factory to secretly modify the electronics that permeate our lives, making it possible for the Chinese government to monitor everything that everyone does at anytime and anywhere. If this were a joking matter, one might believe that this is little more than jealousy on the part of America's covert ops industry. In addition to this order, the US Commerce Department took additional measures by adding Huawei and 70 affiliates to its "Entity List", which bans the Chinese telecom giant from buying parts and components from US companies without US government approval. Earlier today Google signaled its logical intention to comply with the revised laws by suspending some of its business with Huawei. Other companies outside of the United States that provide hardware and software to Huawei are also cutting the company off in an effort to stay on good terms with the US government.

This leaves Huawei, the second largest mobile phone maker on Earth, in a bind. They cannot get all of the parts they need to build products. They cannot get access to all of the services that Google offers people who use their Android operating system outside of mainland China, which will give potential customers a reason to not buy a Huawei product. Their other products, including TVs and traditional computers, will soon face a similar series of problems.

The people in leadership roles within China will not take this lying down. Huawei and other companies will not have their livelihoods held for ransom every time a foreign government, be it the United States or someone else, decides to issue a decree. The Chinese government could react with a number of measures, but many of these would just hurt their own economic position. Rather than lower themselves to an endless game of action-reaction, it may be time for some of the technological innovations in China to replace those developed elsewhere; a technological split from the west, so to speak.

Zhaoxin is a viable domestic alternative to Intel and AMD for x86-based processors. Kylin is a modern desktop operating system that is certainly up to the task of replacing Windows and macOS if people were so inclined. Huawei has been working on their own fork of Android for quite a while and have even hired some former Nokia people to make it happen. Next generation RISC processors are open-sourced, meaning they can be used by anyone regardless of a government order. It wouldn't be easy, but there is no reason why Chinese corporations, with the support of their government, couldn't "fork" current technologies and begin diverging from the products developed primarily in the United States, Europe, and Israel. In the space of a decade, China could be a technological Galapagos, much like Japan was in the 90s. So long as the Chinese business leaders are smarter than their Japanese counterparts, then it wouldn't be too much of a stretch to see Chinese technology begin to replace western technology first in developing countries and later in developed nations.

The parallel development of technologies would probably appear to be a duplication of work at first but, within just a few short years, a noticeable diversion would become apparent. Customers would vote with their wallets. Markets would expand and contract. Companies would adapt or fade from relevance. The reality is far more complex than a 700-word blog post might make it out to be, but a technologically independent China would have a lot of benefits. Not only for the people of China, but everyone around the world. A technological race to domination would drive a lot of innovation and require a lot of intelligent people.

The rising tide raises every boat.

Of course, this could also backfire and result in drastically incompatible systems. I'm optimistic that we would see more good than bad from a technologically independent China, though.

Discoverability

While digging around for some new comedy podcasts I started thinking about podcast discovery … again. There has got to be a better way of doing it than relying on multi-billion dollar companies that already control too much of our art and culture mediums. Jeremy Cherfas is working on something interesting that will help people learn about new shows. Gimlet and CBC1 also have their own variations of something similar. Of course, one of the biggest problems that people will face when it comes to finding new content revolves around time. We only have so much of it, and digging around in the various directories will only serve to expose the shows that are already incredibly popular, but not necessarily the best.

I didn't talk about this during the podcast, but one idea I've had rolling around in my head is to essentially make a few "stations" online that people can dip their toes into. I would build robots to monitor a number of social networks and spot podcast links. Shows that are mentioned often will be inserted into the station, and people can come listen at any time. Downloads would come from the host server — not my own — to ensure the creators are seeing accurate numbers, and the more common shows from big publishers would be weighted against lesser known shows to ensure a rich mix of voices and ideas. I already have the algorithms in my head that would make this all possible with very little effort on my side.

Well … no more than a week's worth of work to develop the entire infrastructure and the site people would visit. But what's a week?

The nice thing about having downloads come from the origin server is that I would not be on the hook for a bunch of bandwidth charges, and I wouldn't have to worry too much about throughput speeds. That would be the onus of the creator, as it should be.

Would people listen, though? The "station" would allow for live streaming online, of course, but it would also be little more than an RSS feed that people could subscribe to and listen while out and about. But an RSS feed that fills with 24-hours of audio every single day is way too much audio. There would need to be some sort of filter in place. Maybe limiting the total playlist time to three hours a day? Two? Heck, a person could create their own custom feeds2 that include only shows that fit in certain categories with certain criteria. It's certainly an option.

Does something like this already exist? There are lots of podcatchers that collect an awful lot of information about what people are listening to …

I'm not sure what the best answer to podcast discovery is. I know it isn't some convoluted, complex mechanism that involves passing through the gates of some Silicon Valley company, though.


  1. Yes, the Canadian Broadcast Corporation. Who'da thunk it?
  2. I would do this in such a way that nobody would have to give me personal information or even create an account. Custom RSS feeds are dirt cheap to produce.

Details

Apple replaced Google Maps on iOS with an internal alternative almost a year ago and, in the time since, has worked night and day to make their system as good as the competing tools, if not better. The first few months were rough, particularly for people living outside of the United States. Our maps showed outlines of buildings, but had no information as to what the buildings were. Train stations could be inferred, but no names were available in the system. Directions … were just better left alone. That said, the tool has become a lot better in the last six months as teams around the world continue to add location information. That said … Apple Maps is still not quite good enough to unseat Google as the premium mapping tool.

Comparing Apple and Google Maps

On the left we have Apple Maps. On the right is the Google Maps service we see though Mobile Safari. See any difference? I see a big one in the form of public transportation information. This information is utterly invaluable to a person trying to find a very specific location in an unfamiliar place; like earlier today.

I decided to take a short walk between lessons this evening to clear my head and wet my whistle. While standing outside the convenience store, I was approached by a person who was lost. They spoke English, and were clearly tourists1. They wanted to know where Nagoya Station Exit 1 was.

I have no clue.

Japan's world-renowned transportation system makes use of a lot of underground passageways that are identified by numbers, letters, or some combination of both. The nice-looking tourist who asked me for the location of Exit 1 was hoping for a simple point in the right direction, and I wanted to help out. My weapon of choice? Apple Maps.

Apple Maps, despite its lack of rave reviews, has often provided just enough information for me to find what I was looking for. Today, however, it had nothing for me. No matter how far I zoomed in, there just wasn't enough information for me to find what I wanted. I needed something better, and quick. So it was off to Google Maps in the browser. 30-seconds later I had my answer, pointed the young lady in the right direction, and made my way back to the office for the last few hours of work.

Google saved the day when it could have been an Apple success story. It should have been, too! Alas … I digress. One thing that I would like to see happen in the near future, though, is a crowd-sourcing tool built for a mapping application. A lot of the information in both Apple and Google Maps for the area surrounding Nagoya Station is terribly out of date. Many of the buildings, government offices, and bank branches they list have long since been relocated due to all of the construction taking place. I think the average citizen would be more than happy to help fill the gaps in the information these products provide.

Platform Lock-In

Over the last few days I've had the opportunity to communicate with a number of people who, like me, are moving away from Google. While this sort of geek march is not very interesting to anybody1, what is interesting is the number of people I've seen considering dropping their Android-powered phones for something that is not under Mountain View's control2. The problem they'll have, though, is a remarkable lack of choice when it comes time to pick up a new smartphone. There are only two viable options for people who want to walk around with a little computer in their pocket while avoiding Google.

iphone5_WinPhone

So I guess the only question is this: which platform do we want to get locked into when we really don't have a say about which services get killed by any of them?

I look forward to seeing how many geeks actually go through with their "Say No To Google" plans over the coming months. Perhaps this is the break FirefoxOS needs to beat Blackberry for the 5th spot in mobile operating system usage.

The Funnel

Like a dozen developer teams around the world, I've decided to throw my hat into the Google Reader Alternative competition with something of my own creation. There have been a number of features that I've long wanted to see in an RSS reader so, rather than use another service that may not have the items I'm looking for, why not throw caution to the wind and set something up that other people can use? I call this latest creation The Funnel.

There is still quite a bit that needs to be done, but the foundation is already complete. Believe it or not, The Funnel will be working off the same foundations as Noteworthy1 and 10Centuries. The initial release will be a web application that works in conjunction with an API that any service will be able to connect to. Further iterations will have some of the more interesting functions that I plan on building into the service, including the ability to choose among several different themes and use custom CSS to make things look just the way we want it to be.

Shortly after getting the main web version 1.0 out the door I'll start work on the iOS client, which I believe will be modelled heavily after Wedge2, and the RSS Reader I've been using for the last few years, Byline3. The initial design won't stay this way for long, but it will provide enough of a foundation to get the main functions out the door and in people's hands.

There's just one little thing that might hold it back; a subscription model.

Hosting RSS feeds is not going to be cheap, and some of the features that will be built into the system will require quite a bit of computational power as well as storage space. These things aren't cheap. While the exact price hasn't been worked out, the goal will be to make something that breaks even with very few subscribers. $10 USD a year or less is the ideal that I will aim for, and it really shouldn't be too difficult to keep it within this budget.

This is an area that is going to get very competitive very quickly. July 1st, Canada Day, is the last day Google Reader is going to operate, and developers are gearing up to get their solutions out the door well before then. Like almost everyone else, my day job will get in the way of progress. That said, it will be very interesting to see how the market works itself out in the coming months.

Quit!

The Ides of March have long been associated with the assassination of Julius Caesar but, with only 365 days in a year, a lot of bad can happen on the same calendar date. Of course a lot of good can take place as well, and this is how I'll look at the painful transition I've now successfully completed: quitting Google.

Truth be told, I didn't think it would be this easy. I wrote yesterday about some of the issues that I would have replacing two of the more important services I use, mail and contacts. However, after just a few hours at FastMail1 getting the account set up with a two-month free trial and pulling in 15-odd years worth of email from GMail, it looks like all of the heavy lifting is complete!

All of my mail has been moved. The contacts are now hosted on iCloud. Mail is being written and read using the default mail app (for now). Custom domains have been pointed away from Google. The GMail account is looking incredibly empty.

A few people have asked me whether I'm ditching Google because I don't trust them or because I'm trying to be an attention whore. Truth be told, it's probably a little bit of both. By actually going through and quitting Google, others might just come here through a Google search2 to see that it is indeed possible. There are some problems, though.

FastMail does not have push notifications, which means that email will seem a little bit slower than it does on Google. The next has to do with IMAP, which is incredibly slow with large mailboxes. I migrated just under five gigabytes of mail dating back to 1997, and the iPod Touch needs a solid 45 seconds just to check the Inbox. This might not sound like a great deal of time, but it adds up throughout the day. Perhaps this just means I should check my email less often.

The other issue that I'm not too happy about is the lack of support for tags. Tagging is something that I've come to rely a great deal on, and it will take a little while to adjust to doing things "the old way". That said, now that the mail archive has been moved to another server, I feel confident in the knowledge that I could do it again if another mail service with superior service avails itself. Until then, I think I'll stick with FastMail.

Now comes the fun part; trying to find ways to optimise email.

Can We Quit Google?

Over the last few years there has been a lot of noise from people like me who have come to the realisation that Google is not the all-powerful and benevolent organisation it has marketed itself to be. These people, much like myself, will vent their fury in blog posts, on Twitter, in forums, and on ADN1 with great enthusiasm for a few days and threaten to stop using any of Google's incredibly useful services … but very little ever changes. People continue to use GMail, the Calendars, Search, and a host of other useful tools that Google has made available at little-to-no cost in exchange for access to our most sensitive of secrets. We can see this cycle spinning up again after the decision to shut down Reader, the most heavily used RSS synchronisation tool in the known universe, so I'm going to do a little experiment. I'm going to quit Google.

Yeah, Yeah … We've Heard That Before

As of this writing I make pretty good use of Google services. I use them to manage my mail across 8 domains and 36 accounts2, my personal calendar3, RSS reader, searches, and I even have some files up in Google Drive that are used to collaborate with clients from time to time. This isn't extreme by any stretch of the imagination, but it can be a little difficult to find adequate replacements … particularly when the Google tools have been so damned good4. But I'm going to try to do it anyway.

The question, however, is how.

The calendar is easy, as we can liberate our data from Google Calendar with the export function. From there it's just a simple matter of importing it into the calendar tool of our choice. In my case, I moved to the walled garden of iCloud. A bit of the data had to be massaged and cleaned up, but this allows me to work with the calendar on my Mac, through a browser5, and iOS devices.

Google Drive is even easier to replace. Dropbox does everything I really need when sharing files with clients, and I've never been a fan of Google Docs. Migrating everything from Google Drive to Dropbox took all of 2 minutes.

Contacts and mail, however, are the two tricky areas. If I move all of my contacts to another place before email, then it will be difficult to keep the two contact lists in sync. Moving to iCloud would be simple enough, but it would make more sense to keep the contacts in the same place as email. So what the heck should be done about email? It seems like I just moved to GMail!

The common recommendation on ADN is that people switch to FastMail or Outlook, but I could also go back to hosting self-hosting. It wouldn't be as versatile or convenient as a solution hosted elsewhere, but it would put the control back into my hands … along with all the spam.

Perhaps the most difficult thing to replace, though, will be search. Despite the recent reduction in Google's accuracy, it's still the best solution out there. DuckDuckGo is getting better, but it's still not as good as Google for providing the information I'm looking for.

Will there ever be a paid search tool? Will Bing ever catch up to become the better solution? Only time will tell.

Although I doubt it will be possible to completely ditch Google, it will be an interesting little exercise. The question I have now is how many people will actually follow through with their  threats to ditch Google 

RSS: Really (Not) So Simple

A lot of pixels have been spilled over the last 24 hours as people lament Google's decision to kill off their RSS Reader aptly named Google Reader. The writing has been on the wall for years, but most people seem to have lulled themselves into a false sense of security with this one particular web service thanks to the number of 3rd-party applications that make use of the unofficially-released API. Since Google's announcement we've seen a number of people asking already popular RSS reading applications to lead the way to build a new synchronisation tool using other services such as App.Net or some other already-popular website. While it's certainly possible for another group of people to come together and build something that resembles Google's Reader, the real solution might be something very, very different.

Who are the main people who make heavy use of RSS? People who read, of course. People who set aside a good portion of their day to stay abreast of events happening around the world use RSS as a means of keeping themselves up to date. Take away the RSS feeds, and people are stuck in the pre-Google Reader era where RSS feeds need to be individually retrieved from websites along with the appropriate resources … or worse. Before RSS really gained traction people would go from website to website every day and share links through email, IRC, and instant messaging.

Madness!

We will certainly not go back to the days before Google Reader exploded onto the scene to provide a one-stop location for all of our RSS consumption, but we might see a little bit of staggering as people start to think about the various things an RSS synchronisation service needs in order to fully replace what Google once offered (for free) and, hopefully, propel the use of RSS even further.

What I'm Looking For In a Replacement

I've worked on projects in the past that were supposed to grow into replacements for Google Reader, so know first-hand how difficult it can be to develop a system that everyone will be able to use, appreciate, and enjoy. One of the biggest hurdles that the team and I faced while building the tool was finding an effective way to stay on top of fresh content. No two websites are alike when it comes to a posting schedule. Some will have fresh content every few minutes, while others are updated once or twice a year. What is the best way of ensuring that the sites with infrequent updates are checked for new material within a timely manner? Sure, there are algorithms that can be conjured up to scan heavier sites every few minutes and less-busy sites every few hours, but this seems like an awful waste of resources.

At the end of the discussion the one tool that we all agreed was likely to be the most effective solution was a Feedburner-like service that sites can ping whenever there is an update ready for consumption. Any replacement for Google Reader would likely want to institute the same sort of mechanism in order to give people incentive to use the service, and an easy-to-remember RSS Feed URL with readership tracking sure seems like a great way to get people onboard1. So any single RSS solution would have to have a Feedburner-like solution available for people to use.

Synchronisation is also a huge deal for many people who read news across multiple devices. If we've read a post on our phone, then our tablet, web, or desktop reader should also know it's been read and leave it as such. Nobody wants to mark things as being read in one fell swoop, because it leaves too much to chance. This means that a central database will be required to know which articles have been read, and which ones have been skipped … perhaps to be read later. Using some simple tool like "I've read up to this specific date-time stamp" is not good enough. It needs to be post-specific … which is very database heavy, but not impossible. So any single RSS solution would have to have post-specific read receipts.

Search is something that I've yet to really see implemented effectively in any RSS reader to date. I read an average of 1,700 articles every week through RSS feeds, and I know there are people who read far, far more. Searching through past feeds is a huge pain in the ass. Google never has the exact answers we're looking for, and trying to remember exactly which site had what content that we want to reference can be a chore in and of itself. Some people will star interesting articles to make searching easier later while others will send the article to a 3rd-party service for better indexing, but this is hardly the best solution out there. So any single RSS solution would have to have a really good way to search through past feeds that we've subscribed to2.

Finally, the speed at which feeds are downloaded will be the make-or-break feature of any single RSS solution. If we were to go back to the old days where an RSS reader had to manually fetch a single feed for every site, updates would go from completing in under a minute to a 10-minute trial of patience. Not every site has instantaneous response times, and the downloading of web content such as images can take a really long time for people on self-hosted solutions who don't want to spend ridiculous sums of cash on a CDN3. Every post would need to be stored locally on the server of the RSS solution … potentially with a copy of the content4. This would allow updates to happen in a very short time with a single JSON or XML response from the main RSS service.

Not an easy thing to do at all, considering how much storage space would be required in a very short amount of time.

Of course this centralised service would also need to play nice with existing RSS readers on all the major platforms5.

Looking Forward to the Summer

These are four of the areas that I feel any new RSS service would need to address in order to become the new defacto RSS tool for people all across the Internet. We likely won't see anything like this right away, but we may see something with a great deal of potential before Google Reader shuts down for good on Canada Day. My only concern is that instead of seeing a little bit of innovation in the RSS field, we'll see more of the same with all the limitations that we've had while working with Google's Reader and Feedburner services over the last half-decade.

I hope I'm wrong.

Google's Ambition

Google has recently ended months of speculation about the existence of a new Chromebook device aimed at the pro market with the Pixel, a machine equipped with many of the same internals of a 2012-model MacBook Air but with a much, much sharper screen. Looking at just the hardware specifications of the unit, it's certainly something that a lot of developers might enjoy, and it would even be a great little unit for people who enjoy whiling the day away on YouTube and Google+. There's just one little question I have: will it still be a productive unit when there is no network connection available?

What's interesting is that Google is positioning this notebook as a reference model, similar to what they do with the Nexus-branded Android phones. By looking at what Google is doing, other manufacturers will be encouraged to develop their own units with similar or better specifications. Looking at the image above, one of the first things that strikes me is the 3:2 aspect ratio of the screen … something that most non-Japanese manufacturers moved away from five years ago. What could have inspired Google to go this route over a 16:9 screen?

In all honesty, I believe this notebook will see greater adoption than the Ubuntu-powered notebooks that have been sold by HP and Dell over the years, but it won't be a very large segment. One area where I can see something like this taking off, though, is the business market … particularly for businesses where Microsoft Office is not an absolute requirement.

Google's Hardware Push

I've been thinking a great deal about Google's hardware pushes over the last year. The Nexus devices have not seen a great deal of adoption outside of the hardcore Google fans, but two other projects that are on the cusp of release are starting to gather a great deal of attention and enthusiasm. Chromebooks such as the Pixel is one area, and Glass is the other. The Verge recently ran a really good article outlining this ambitious wearable device.

With Google moving more towards a hardware role people will have the opportunity to use Google's powerful software in a more natural setting, which should improve usability as well as the entire experience. If the company plays it's cards right, they'll have a very Apple-like infrastructure in place where Google-branded hardware is the best option for people using Google-powered services. Unlike Apple, however, Google's services will continue to be multi-platform. This will ensure that people can very easily migrate from one system to another without any transition pains whatsoever, which is something that Apple will never be able to do. There's just one little problem that Google will need to fix.

Where are the people?

Have you ever tried to talk to someone at Google? There are no phone numbers to call when you're having trouble. Using the various forums set up for products can be helpful at times, but it won't be a Google employee helping you. Want to get some training? Good luck talking to somebody.

Google has done a lot of things really well over the years, but one consistent trouble spot has been effective communication with the people who actually use their services. Unless this area can be addressed, and fast, any traction that Google may hope to gain will be lost as people run into edge case problems and abandon the hardware like a Honeycomb-powered Motorola tablet. I'd love to see Google succeed with a number of their products, particularly Glass, so let's hope they solve this final hurdle with typical Google gusto.

Google Maps Doesn't Need A Network?

A few days ago I was surprised to discover that the Google Maps for iOS app did not require an active network connection in order to determine where I was and show my current location on a map. I had some theories as to how this might work, but wanted to test it out a little more. I have a 5th Generation iPod Touch which, as many people already know, does not come with a GPS or a constant network connection. I do not have one of the many public WiFi accounts1, nor a portable data device. When I am out and about, I am without an Internet connection 99.8% of the time. So, to put Google Maps to the test, I checked it out at various points around Central Aichi prefecture while making my way to various client offices. The results were rather surprising.

No Network Required

Believe it or not … no network connection is required in order for the blue dot to know roughly where you might be, though the situation is far from perfect.

Throughout the day I checked my location a number of times. The picture above shows the last two attempts. The left side map correctly shows my location at 勝川駅, and the left at my home station of 春日井駅. The blue dot followed me all the way from 刈谷駅 between Nagoya and Toyoake all the way to where it's seen in the screen shots. I find this absolutely astounding. How can an application with no network connection know roughly where I am along 65.9km of a rail line where 40km of it is travelled so rarely that I can count the number of times I've been there in my life on one hand? It boggles the mind, and gets me thinking.

If I were to build a software tool that had this sort of functionality, I would try to cache as much locally as possible. This would include basic maps with common zoom levels, and what geographic locations the person typically opened the application at. That last bit of information would give me a great deal of confidence to know just how much and what should be kept on the local device. Approximate GPS locations can be determined by triangulating a bunch of WiFi routers and checking their SSIDs against a database stored on the Internet but, without an active network connection, how can these SSIDs be checked? Does Google Maps keep a list of 100,000 network routers cached locally in the event I want to walk around? Are they allowed to do this?

I've searched a number of sites to find out exactly how Google works its magic with this little feature, but there doesn't seem to be any answer. This tells me that either very few people use Google Maps on an iPod Touch, or nobody seems to think this is very cool. The web browser version of Google Maps has had similar functionality for several years now, but desktops also have a lot more memory, storage, and processing capacity to handle all of the extra data. Mobile devices are typically stymied in this regard. One thing that I would really love to see is the option to download detailed maps of the areas that I frequent or pre-research. I'd gladly give Google Maps 2GB of storage space on my iDevice if it meant that I'd have a pretty accurate map of the surrounding areas for a radius of 200km. Sure, it's a bit excessive, but it'd be worth it in a pinch. I wouldn't have to pay the phone company 8,000円 a month for the privilege, either!

Perhaps a future version will be more customizable …