The Idea Repo

Behavior based ad-blocking

2016-02-04T21:05:00.000-08:00

Ad-blocking can be contentious. Ads after all are the backbone of many popular sites and because we've unfortunately trained the public to not pay for anything on the web it's likely here to stay if we want content. At the same time many, many ads are bad. They can eat bandwidth, distract visually, decieve users, are a common source of malware and and just generally annoying. Ad-blocking is not unwarranted for this reason, just because I want to see your content doesn't mean you have your way with my browsing session.

The problem, as I see it, is that add blocking is primitive. Virtually all are some combination of black-lists and white-lists. That does the trick, but it's really heavy handed. In most cases the default is to just nuke everything. But we can do better. What if we actually looked at the ad itself and decided whether or not to show it?

There are some obvious things we can look for:

Sudden fullscreen or modal content usually indicated a nasty UI blocker ad (or just bad UI).
Flashing or high motion
Heavy scripting or content download originating in an iframe is an indication of a resource hog ad.

These things can immediately be filtered as we generally want to remove misbehaving ads however they come. Seems like a deep learning job to me.

On top of that there are other general things that would simply disqualify ads:

Not in user's language
Not advertising for users location
Repeated

In this case it's not useful for either the ad company to show the ad or the user to see the ad, so just get rid of it. I think this needs to be how we design future ad-blockers. We don't want to kill income but we do need to be smarter about how we deal with it because there are lots of bad ads.

Activity Tracking and Data

2016-01-01T23:28:00.003-08:00

I recently received a pedometer from my insurance company. They have a program where if you walk a certain amount you get money back on your insurance. This is a good idea and incentive to get people a little more active beyond their own internal motivations and the insurance company clearly recognizes that it will benefit them to have healthier subscribers. The problem is that I already have an activity tracker, a Pebble Time watch and my wife has a Fitbit. This creates an irritating situation where I'd like to participate but I need two tracking devices. The insurance tracker is unsophisticated and has terrible battery life. Instead it would be nice if they could just use the data I already collect from a device I like much better.

Apple and Google of course are already attempting to do something like this with HealthKit and Google Fit which can aggregate data from many devices into a standard (ish) API. But there's a lot of other questions this raised with me.

Who should really control that data?

While there is great value in standardizing that data, the question is who should do it. Obviously all solutions are pretty self-serving. Neither Apple or Google are especially prevalent in these markets but because they control the phone market via a duopoly it's easy for them to use that position to push people into their service and consequently gain a lot of lucrative data while doing little to no actual work. I'm not sure I really want that. Fitbit does it's own thing and that seems fine but other devices aren't going to feed into that ecosystem. In many ways it does make sense for competitive purposes to silo it by device but there are also some other reasons like standardization why this might be necessary. So, if that's the case, does it mean that my insurance company should integrate multiple APIs? I think they should but they're an insurance company so they won't and I guess I'm stuck with a crappier version of something I already own.

When is a step a step?

So as nice as it seems to aggregate this data, we don't actually have apples to apples among providers of this data. For pedometer data which is notoriously not accurate it might not be a big issue but if we're to move into better and perhaps more medically useful data we kinda need this. Pebble has a cool idea to open-source their motion tracking algorithm and that's a good start to something standard. Though, we also need to know polling frequency, accuracy, drift etc of the sensors to really get there. This is hard but maybe we can set up a minimum standard for what is allowed to measure a standard "step." Then we have to standardize where the device is worn, on a hip gives a much more accurate reading that the arm because it's close to the center of mass. We need to sort this out otherwise we don't know-

How to aggregate it

In my case, I have 2 devices I could use plus a phone, but most people will have a phone and a wearable. If I forget or don't want to wear my wearable it'd be nice if my phone can sub knowing it might not work quite as well. But if I have my wearable it'd be nice if that data is used instead. Here we'd want to be seamless so maybe a accuracy score is necessary to pick the measuring device to use. It seems we'd also need a timestamp to sync the readings and filter out where there is overlap.

How do we secure it?

Hacking and stolen data is bad but that's not even of super important concern to me, we have standard, time-tested ways of dealing with it. The more interesting problem is the authenticity of data. For example, my insurance company probably doesn't want me to attach their device to a ceiling fan to generate readings. While better algorithms can detect some cheating not all of it will. Say I had a game based on motion readings, perhaps a virtual marathon (perhaps with donations). This seems like an interesting use case but I also can't be certain cheating isn't an issue. So we might need other metrics to go with it, like a heart-rate that's harder to fake. Perhaps the sensor-fusion algorithm itself needs protection on a hardware level. At the very least we could take multiple measurements and give a score of how likely such a reading is a real human doing the task expected.

None of these seems like they have easy answers but for activity wearables to really get to the next level, we need it. How can we standardize these things in a way that doesn't just try to bulldoze one another.

Bumper Cars

2015-12-21T08:57:00.000-08:00

It occurred to me after watching my friend's car get bumper damage from a truck that basically parked on top of him that bumpers aren't really all that smartly designed. Despite protecting the frame they can still be plenty costly themselves to fix and really easy to damage but more importantly it doesn't well protect in these sorts of scenarios. While I think a real rubber bumper would be best, perhaps people will hate it because their car looks ugly. As much as I could handle that eye roller of an excuse why don't we standardize the height of all bumpers? It should be the case that all collisions always happen along the bumper, this should instantly minimize the amount of damage from slower collisions and probably increase safety by making it more predictable.

Physics simulated audio and hardware

2015-12-12T16:29:00.000-08:00

I'm not a audio snob but I do often hear the arguments of them. People have strong opinions about what sounds "good." This can get highly specific, into things like what wood a violin is made from. In computer graphics we typically have two strategies to produce images. One is raster graphics, a sort of brute-force approximation where we represent the image as pixels and need progressively more space to get more detail (but little computational power). The other is vector graphics which scales indefinitely and is comprised of the "instructions" to produce the image and requires computational power but little storage. Both have their places. In audio we don't really have many analogs or at least one is far less used than the other. Raster graphics basically equates to all types of audio files people are familiar with. MP3, AAC, FLAC whatever. These are at their core just samples over time. The vector format of audio would be something like MIDI where a bunch of samples are played in a script (instructions), not unlike written music. I don't think this really goes far enough. The samples are usually pretty set or at least they don't tend to change and aren't easy to change. To this end it makes sense to me to have a format based on physical simulation of sound. This means that instead of a static sample we try to simulate the material properties to get sound. Of course such a scheme would be very computationally expensive. This is a prime candidate for offloading onto specialized hardware. In fact GPUs are a good analog, perhaps we have audio processing units and programmable sound "shaders" to create sound. This is could be great for music creation, and games especially. But it might also be interesting to see small but lossless files that can produce excellent sound quality and music. Maybe even digital musicians that have slight variance each time they play.

Software Engineers

2015-11-07T12:57:00.005-08:00

The Atlantic published an article I thought was interest about the use of the word "Engineer" in a job title that got a lot of attention.

http://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/

While it highlights a recent phenomena I couldn't really agree with with much of any of the arguments presented for why it's problematic.

I think the overall call to action is pointless. Language governance doesn't work, nor has it ever become a real problem. Languages evolve organically and definitions are based on usage and change over time. If large swaths of people do not consider "engineer" an official licensed designation then it isn't or at least not to everyone and not in those contexts. This form of demanding restriction almost always spawns from elitism. The French for example have laws governing the usage of certain cheeses or more famously "champaign" which is only for sparkling wines from that region. Of course common usage doesn't care, but I'd hardly argue it's confusing. Likewise "Kobe beef" is a very special beef never exported outside Japan but is consistently used for other forms of wagyu beef that get exported. This happens a lot when people want to protect a brand, and that's I think the heart of the issue here, engineering™ is a brand that the author wishes to protect and unlicensed usage "cheapens" it. Though in reality if people desire to use your brand, it's not cheap, it's prestigious.

Of course while that's easy to write off, but there are some things in the article about the perception of software development, as well as some criticisms, that I think are great things to address.

The author uses credit breaches as examples of engineering failures on the part of software "engineers." This I find is frequently one of the most common misrepresentations of software development. "Lazy devs" is a commonly used phrased in the circles of video gaming and yet in most cases, these people are not lazy at all. Software varies in many ways from physical engineering but greatly in product management. Imagine if you were building a bridge and you do not have the budge to re-enforce it and must complete it 6 months faster than you think is reasonable. Imagine you work 50-60 hour weeks for 4 straight months. Do you really think that even with the absolute best of the best the product will be well built? That is the reality of much software development. This is not about the quality of devs but the quality of companies and project managers and people writing checks. The problem isn't about titles, but that if a bridge doesn't meet external inspection there are going to be lawsuits if not arrests. Software rarely needs to meet such inspections. We do have them however, online stores often desire to meet PCI compliance. The problem is that it is not enforceable and certifications are easily abused. We can improve here but I don't find this is terribly related to what we're called.

You could imagine making such checks mandatory and that would fix it or at least part of it. But who makes it so? The government? Governments do participate in compute related standards but unfortunately it's been a complete disaster. The US government pushed encryption standards it knew were weak so that they could abuse it. The US only recently called off the witch hunt on strong encryption but places like Great Britain and China are moving forward. Governments do not have the public's best interests in mind in terms of software and so in such a climate it would be crazy to think they would be fit to create the framework. So if not a legally enforceable framework, we're really only left with opt-in.

Standards on software are also hard. Things change yearly and there is strong desire to make that faster. New attack vectors and new mitigation strategies come up all the time and there's no good way to keep up. That strong encryption that was best practice might be significantly weakened in 5 years and you can't know that ahead of time. You must change things and so you must break things. Facebook was actually right, you need to set the expectation of change and response, we as responsible software engineers cannot allow people to rest on these products until they are completely decommissioned and that will impact some negatively, it's unavoidable.

We do however need to make software resilient. As a strong critic of the cloud I don't think that should be the norm. All software should consider offline first and progressively enhance for the network. If Google docs goes down we do need recourse to use local networks and what-not. Things happen, and we do need to be responsible for that. But again, that's not about titles, that's about the people who give me my paycheck doing the right thing and letting me do the right thing. I want to do that, nobody has the budget for it, it's not important enough to the business.

Even if we could find a certification solution what does it mean? I have many certifications that don't mean much at all. They are hard to verify and that's important because the end user of the product does not request that it is only made by certified software engineers. They don't even know who made it most of the time, let alone their credentials. Even if they did would they have the expertise to really know what I'm expected to do? My process of testing, code reviews and disciplined development? If not then what good is it? Realistically certification is for resumes, my employer cares because hopefully they care about quality but the end user gets whatever my employer/product owner gives them.

So we can't really have what the author asks for but does it matter now? Yesterday I talked to a person with the title "Solution Engineer," Is that confusing? I certainly had no expectations about their responsibilities to me, I don't suppose others do either. The cleaning guy might have a title "Sanitation Engineer," again I don't think most people mistake that for someone doing strong diligence to avoid garbage related mishap. If anything that's not how others refer to them. "Customer Specialists" are clerks, "Sanitation Engineer" is a janitor and while my official title is "Software Engineer" I'm often just "developer." It's not an issue I think others struggle with, it's a fancier title.

But from my point of view I like being called an "engineer," I went to an engineering college, I have the prereqs any other engineer would have. Developer and programmer doesn't encompass what I do. I'm not interested in just writing code, I take pride in building a product that I think works as best it can. I take care to test, secure and anticipate and make it as good as any engineer would. You absolutely have no guarantees of my quality based on that title but what's important is that title explains to you what expectations I have for myself and what responsibilities I take. I'm not cheap work, I intend to give quality code, not code done quickly or on a budget. That is why we took that word in the first place, not so that people would think we're something we're not, but because it describes how we feel about what we do. How you interpret it is up to you,

Set-based image compression

2015-10-06T20:56:00.001-07:00

Typically when taking pictures they are taken in sets. The colors and subjects will often be very similar. In fact we can perhaps predict that they will change slightly over time not unlike a movie. To this end I think there could be merit in compressing across sets of images rather than the image itself. This might be more useful for archival but even of the web with image heavy sites we could compress the set as a grouping and save a lot of data.

Hardware Power Switches

2015-07-28T20:20:00.001-07:00

Most devices these day have some sort of mechanism where you hold down the sleep button to turn off. This to me is a fine general feature but it kills me when there is a bad software problem. Many times I can't even turn it off and this is the worst. Realistically all devices should have hardware switches to cut the power, they can be hidden under a battery compartment or something (non user replaceable battery? We can outlaw this while we're at it) but it's something I think is an important last resort for when something goes wrong.

Personal Wireless Serving Device

2015-07-25T11:42:00.001-07:00

Mobile devices are a fixture of the way we do business but there are many limitations to them. They tend to take a functionality nosedive when there is no wireless connectivity, they operate on battery and have to maintain very strict size restrictions. It's not just phones but tablets, wearables and game systems. There is a large market of devices that attempt to fix some of this, these would be portable battery packs, special wireless external storage (because many devices can't or don't have SD card support) and mobile hotspots. My concept would be to take aspects these supplemental devices and transform them into a hardware platform of sorts.

The core idea is a small device, maybe not pocketable but could fit in a bag or purse that offloads a lot of the functionality that one of these devices might need. The obvious one is a connection to the internet. The device could handle jumping between hotspots perhaps with multiple antennas and managing them. This means that even a fairly simple mobile device could have much better overall reception. It might even be possible to build up offline caches for when connections aren't available. This would require a lot of storage not available to phones but could be fairly easy for a larger device to hold. The idea is that at least something could be provided when out of range of an access point. It's also possible you build the cellular connection on the device. In this way all of your devices can access it but the benefit is that maintaining 4G connections can be costly on battery but offloaded you could say connect with low-power bluetooth for incoming things like phone calls and then switch over to full wifi to pickup, providing a big boost in overall battery life.

Another feature would be storage. We're all pretty familiar with the dreaded "cloud" but such a device could create a more personal version of it. Store a whole music library or all of your photos and access them wirelessly. There's no shortage of ways to manage storage but this could offer a nice unified way to do it whether online or offline. Again because the device doesn't have the same restrictions you could shoot for terabytes rather than gigabytes of on board storage. In addition it could provide additional security for users as they would not have to trust more sensitive data to the cloud.

In more interesting usages you could use a much bigger CPU/GPU on the device to enhance the processing abilities of a phone. Imagine the ability to be able to run voice or visual search queries without going out to the internet because you have the processing ability to do it where you are. Maybe even remote rendering or processing like cleaning up or tagging photos and video with much less of a battery impact. The cloud has high latency but something in the same space could be much more usable.

The last part could be apps. Like server apps. You could run locally things like content servers, media servers, web servers or interesting things like network-level ad blockers, peer-to-peer sharing and all sorts of other cool stuff. I imagine this is where a lot of money could be and if the apps are cool they could really gravitate people toward the device.

Maybe we could also offload expensive peripheral items like speakers or quick polling GPS as it would have space and battery life to do these tasks.

I really feel a sort of inbetween device could have a rather large impact on the way people interact with mobile devices and the best part is, it will always default to back to the device if not present.

Work, Play and Pay

2015-06-17T05:54:00.000-07:00

People need work. Work is a stimulating activity that gives purpose and trains us to hopefully be better people. Although, while this is true the current system is pretty arbitrary. 8 hours a day, 40 hours a week is something we pulled out of a hat, it doesn't fit every job or every person. Perhaps a result of this and for stress insulation people tend to work down time into their job, small bits of time to do other things, talk to co-workers, browse the web or take a smoke break. If you ever find yourself in a job that doesn't allow this, you are on a one-way trip to metal breakdown, fatigue, poor health and maybe even substance abuse. Of course these little pieces of down time cause job related social problems, namely "are you working hard?" Now working hard and getting a job done are actually two unrelated things but it's often recognized as both. The main issue here is "are you taking advantage of me?" I'd argue from a more social equality standpoint that like a white person wondering if they're being discriminated against this is rarely a question businesses should ask because the system is too stacked in their favor. I think the solution is to recalibrate how pay is given out. Ideally pay should only really be about the value that a person adds to the company, not hours worked or checklist items complete. Quality comes in different ways and different people have different means of getting it, whether that be all-nighters or frequent breaks. So a business should be less about micromanaging and better about figuring out the value of individual work regardless of how it gets done.

Note that there are other complications with client work which I'd like to detail sometime but overall this shouldn't change too much.

Web for Wearables

2015-02-28T11:59:00.000-08:00

I've been tinkering around with the Pebble SDK in anticipation of their new watch. One of the nice things that they've done is provide a Javascript SDK which is much more friendly than the C version. But as I used it, it started to feel like it wasn't really the nice web stack I'm used to but more of a Node.js layer that calls into their API. This got me thinking that there really is nothing like the web for such devices and this is disappointing.

The web has a lot of advantages. It's standard across devices and browsers, mostly. This means anyone with a device can be compatible with software. Developers are unlikely to support anything that's not a big name like iOS and Android but any device can run web apps which is really nice for the little guys. Also, developers can write once and put it on everything, also nice. But it seems like wearables are going to become highly proprietary, and the same ones at the top Apple and Google are going to be dictating the software (hopefully Pebble continues to excel here).

While Pebble tries to leverage bits the platform there are a lot of reasons why the web as it currently exists won't work well. It has too much overhead for an extremely hardware limited and battery limited device. It's not designed for the same sort of interactions with passive sensors. You don't use more than one app at a time and there's little interaction. You can't just scale things like you can with mobile and desktop. Watches don't have an always on internet connection and if they do it's likely a tether. They get most of the their data from nearby things. They're bluetooth based, not wifi or cellular and so the range is shorter and more constrained.

This to me indicates we need a new platform, especially if there is ever to be a real "internet of things." otherwise it's all proprietary lock-in and late comers are sure to not get any software support. My idea is pretty simple, a sort of web-stack lite. Much of the web now is compatibility baggage that can be dropped but it would also be interesting to target problems found in wearables. How about a typed variant of javascript? ASM.js is already a thing, dumb as it is, but such an idea could be used for the same purposes of speeding up javascript via compiler guarantees and precompilation. What about HTML-like presentation layers? Most other UIs markup are not nearly as advanced and working directly with interfaces in code is difficult. What about reducing that to parts that could work on a wearable (probably don't need paragraphs)? What about ensuring that offline and peer connections are a priority, day one? What about battery conservation best-practices?

I think there's really something that could be explored here and it's uses could also be used to fix current web problems, the same way mobile helped whip desktop browsers back into shape. At the very least it's a chance to start over with the lessons already learned from past failures.

Future web browser design: Feature Blacklists

2015-02-20T08:42:00.001-08:00

The web can really suck sometimes. Browsers can't always drop bad features because they "don't want to break the web." I'm not strong agreer in this sentiment but I can respect it. However, whether or not you believe that there's really no reason why this should impact users. Even useful features can be abused and I think it's important to allow users to revoke permissions for websites that misbehave.

As sort of an extension to my proposal to kill blocking javascript UI, an easy way to do this is to add feature blacklists. Commonly abused features could be disabled by domain or as a whole. These can include:

Window.alert and friends
Opening new windows
Redirecting a page (or filter allowed redirect domains)
Plugins like flash
Audio
Animated gifs
Synchronous ajax
Ajax calls to specific domains
Frames
document unload event handlers
Downloads not specifically generated by "save as"

By default a website has access to all of these. There are some limits like not opening windows except off a click but they can be worked around to produce nasty results. Rather we can treat these more like cookies, websites might want them but we don't have to give them. If it breaks the site that's fine because the user did it to themselves (and if users do block it, the site might have reason to reconsider decisions) but users shouldn't have to put up with crap they know they don't want. Crappy ads, not respecting bandwidth, CPU, battery, locking the UI, etc all of these are preventable without taking away the developer's abilities, just put control back into user hands and give them the ability to say no.

Sleeping Room

2015-01-02T21:53:00.002-08:00

People these days don't get a lot of sleep. This has come to be a fact of modern society. But more than that I'm somewhat convinced we don't get good quality sleep either or maybe we can make it better. Much like some activities we engage in occasionally such as baths, massage, and chiropractics perhaps we can engage in more premium versions of sleep where it's not so much a necessary evil but an activity we can budget for.

My idea is to take a small room, it doesn't have to be big because it's not supposed to be decorative or contain much of anything, that would just consist of a bed. In fact, if not claustrophobic it could just be a bed set into a wall. The room would be sound-proof as much as possible to eliminate outside noise. It should be temperature controlled differently than surrounding rooms that allow the user to select a temperature that fits them best. The last thing would be to have complete darkness with a sunlight that can gradually fade. The idea would be that you can use this to get undistracted sleep in conditions that are most optimal. Set an 8 hour timer and the sunlight will naturally wake you up.

I think such a room installed in house could be very beneficial. It's could be especially useful for partners as others can be very distracting even if the intimacy is welcome. At least some of the time it works to sleep apart to get a restful sleep.

It doesn't seem like it would be too hard to make something like this as all the technology readily exists. If I ever get the opportunity I'd like to take it.

Reinventing the wheel

2014-11-03T18:54:00.000-08:00

Normally and especially in code one would tell you not to reinvent the wheel.  This is generally true, it's often we get a little over-zealous and want to rewrite things in our own style. Sometimes we think we can do it better.  Much of the time this is not the case or at least it's not worth the time or effort to produce a marginally better product, and often times the product you're looking at is better than what you might do.

It's important to keep that in mind but at the same time there is a lot of value in doing something again.  It's often I get code from Github and the like or am told to use something and it turns out it's not very good.  This scales all the way to multi-thousand dollar products which are just plain awful.  Sometimes our resistance to making something causes us to adopt bad practices and bad code.  This might be okay for a novice but as you grow there becomes a time where you are the expert and you can write good code.  It's also important for domains.  General code is often good but once you hit a certain point you need to optimize more toward the goal you are reaching to make appreciable gains.  This is another good reason to roll your own.  This can help not just performance but code cleanliness too.  A library with a few functions is good, a behemoth library with 200 function that you use 10% of is not.  This is one of my cases against things like jQuery, you can do most of the stuff it does pretty easily and then you don't have a whole library to worry about (and maintain).

It's also a necessary component to learning.  Doing something for yourself helps you learn.  It's important to tread the same ground to learn some of the lessons.  If you publicize it can also be a great resource for others to learn or launch their own thing, create competition. 

So we shouldn't take this to the extreme and feel free to reinvent the wheel.

The tablet/phone model won't work for smartwatches

2014-10-19T16:06:00.000-07:00

I've been a big proponent of smart watches for a while now.  While I really want the idea to take off I can definitely see why people would be skeptical of the idea.  While I don't think they have the context to formulate good arguments about why it seems dumb I can definitively say it's due to the current way tech companies are pushing it.

I think the biggest problem I've seen is trying to understand the potential market in terms of phones and tablets, and failing to understand the use-cases.  Applying the mentality and technology found in mobile seems intuitive but it's not, there are very different concerns for watches and it's not just about style.  In fact a good smatchwatch probably share more in common with an eReader.

Active Displays - Normally color is better than no color.  The exception is when adding color comes at a high price.  You can go back to the OG Gameboy and it's contemporaries you don't remember like the Lynx or Game Gear to find that just because something has color doesn't mean  it's better.  E-readers don't have color either but I'd still much rather read on that than a tablet due to the screen properties.  Color doesn't really matter much on a watch.  You aren't viewing photos, or videos, it gives you a little bit of extra flare with UI but that's really minor and potentially distracting.  Both Google and Apple are showing off things with photo backgrounds, not only is that not even close to an MVP feature, it may even be undesirable because that low-res image can muddy the UI especially when every pixel counts.  But despite a relative small-step it cuts deep.  Active screens like LCD suck a lot more energy forcing watches to use dimming, turning off and even then getting terrible battery life.  Pebble went with e-paper and gets 4 days, you don't get picture backgrounds but who cares?  Also active screens have terrible bright-light display making them hard to read outdoors, again passive displays don't have this problem.  This seems like a pretty big use case too, why aren't they optimizing for it?

Distractions - So about that software...  Smatchwatches at their core should display widgets, not apps. Ordering Pizza?  Why would you demo that?  Navigation is also something I wouldn't do on a postage-stamp-sized screen.  People probably aren't going to use a watch as a distraction, after all, they still need their phone at this point so if I have a few minutes I'll get out my phone.  Again we need to optimize for passive glancability, context and sensors.  I think Apple's watch-face demonstration was just awful.  Fly to the planets on the watch face?  People will do that once and then never again.  It's simply not helpful.  You really need to reduce bloat for many reasons because the amount of time spent per use and the limited inputs prohibit it.  Another bad example is the emoji communicator that had sub-menus.  Why would I not use my phone if I have to fiddle with these sorts of menus?  Again an e-readers don't have lots of apps and distractions, instead those limit distraction to focus on the core reading experience which aligns with what smartwatches need.

Waterproofing - Resistance isn't enough.  Being able to thoroughly wash your hands shouldn't be a burden, nor should washing dishes, swimming or rain. Wearables are supposed to be an augmentation.  The more you need to think about it, the less you'll use it.

Of course this isn't to say all is bad, while I think the basics are being sacrificed for novelty, I do think there are a few good ideas being brought in post-Pebble.

Proximity authentication - This is good idea by Google.  This makes it easier to unlock your device and can add up to a decent amount of saved time.

Heart Rate sensing - Watches make great fitness trackers because they combine devices.  The addition of heart rate monitors for fitness tracking is great as it could lead to better fitness tracking and software utility, including medical emergency cases, while being generally non-invasive.

Barometers - A simple device that can kinda predict weather but can measure the altitude change throughout the day.  Another good metric for fitness.

NFC payments - This saves a lot of time and effort when paying for things.  It is too bad that it's just locked to Apple pay as the NFC can do a much wider array of things like pairing or host-card emulation, but for someone who finds themselves with their hands full I could appreciate this.

Communication - Terrible emoticons aside I did actually think Apple's communicator design was good.  Very simple messages are getting popular and because this uses drawn images is has a personal touch which is nice.  Sharing your heart beat sounds a little cheesy but there's good novelty in it especially at a time when technology makes us a little more detached.  I think little flourishes like that are really what can make wearables culture unique.

Killing blocking javascript UI APIs

2014-10-11T18:48:00.000-07:00

There are web APIs that have existed for a long time and a growing problem is that some of them are not good APIs. Perhaps they made sense for the web when they were invented but are becoming more of a liability now. This leaves us with a problem, we could remove them but do to their nature they aren't easily replacable but regaurdless of if they were that easy to replace turning off support for them would cause many web pages, somat the haven't been updated to best practice of the last decade to break. The ones I want to talk about here are: showModalDialog, confirm and alert.

These seem to stem from early GUI concepts of prompting the user with a box that pops up. This also blocks the entire UI until the user interacts with it. This is a terrible UI practice because it's forcing the user to do something or it locks their entire UI. It's terrible from code standpoint too because it's synchronous and the page can't do anything while the prompt is up. What's more is that this actually becomes a security problem. A page can create a navigation handler that pops an alert forcing the user to interact and disabling their ability to close the window, but you can be really annoying and put a lot of text in that alert which moves the clear button past the fold. Now the user is stuck on that page unless they can open devs tools and remove the code. Yikes! It's like a popup on steroids. How has this not been addressed? The answer is simply, too many sites use it. Often for useful testing features or because it's good enough for something simple. This isn't a big problem, those people can change but big corporate websites still abuse it and so browser vendors back off.

While I'm disappointed no browser had taken up the banner (and until someone does this will remain a problem), the solution to me seems pretty easy. I've never seen this formally coined so let me do it, first we start off with inversion-of-blame.

Think about it: If you, the browser, remove it then webmasters will get upset with you. I guess this is bad since it's the sole reason it doesn't happen but anyway, just don't do that, instead because this has user impact give users the option to disable it. If users have the option and you can make good reasons why they should then they will start doing things. This is how popup blockers (mostly) killed the popup. The ironic, sad but potentially useful thing is that users will complain about things they caused and businesses will often bend over to prevent stupid users from shooting themselves in the foot. IE8 is a great example, stupid users use it but if the page was broken they'll complain to the site owner, and so many (stupid) sites still support it. I've seen this go so far as to accommodate user ad blockers or even lack of javascript which is insane.

So in a nutshell, inversion-of-blame is to avoid blame by utilizing a bottom-up update structure rather than a top-down one. Users are always blameless to businesses so if you can reach the user directly you too can share in this magical property.

So to do this we let users disable it. Power users likely will and they might do it for their less technically inclined relatives. That alone should decrease usage. After a while though you can make your argument and set it as the default. You haven't killed anything, it works it's just hard enough that nobody will try unless they have to. This should kill public usage and get people migrating. Business can unset those flags but at this point it's a losing battle for them. You can now take it as public mandate that these APIs suck, usage statistics will drop a you can start removing them completely.

So, any takers?

Security, maintenance and upgrades

2014-10-08T19:47:00.001-07:00

I work with lots of software companies and IT departments. One of the issues that constantly comes up is how to handle updates, specifically from 3rd party vendors. Many still support IE8 despite being 3 versions behind with a very obvious upgrade path (if you're still limited by XP then God help you). This is unreasonable. Software companies should reasonably pass the burden of out-of-date software to their customers. If it was a paid upgrade then I could understand, but for free software platforms we should not support back versions because it is so easy for customers to upgrade and customers that balk at upgrading are bad customers who are costing your business money and opportunity. Keeping these tested, secure and supported costs money, it technically debts the code and incurs maintenance taxes and new features may be incompatible. Checking that box isn't a valid reason, you need clear data that this is worth pursuing and that you aren't going to lose advantages to upstarts without your baggage when things inevitably change.

There's another case with third party libraries. This one is tricky. Obviously we want to be on the latest jQuery or whatever but things change and it can break your code. Realistically, you should have been ready for it. Most of these are good about giving warnings ahead of time about deprecations and changes. I think it's always important to reduce external dependencies if you can but sometime libraries are very useful. In this case it's always important to upgrade ASAP, not just for the features and possible security fixes but because the longer you wait and the more you pile on to old architecture the harder it is to upgrade. You get more benefit and less debt. Yes there is an upgrade cost, but you have to pay it anyway, so you might as well pay upfront. This always happens so it's often best that you continue development continuously and be ready for it, a software product is never finished.

And what if you are the third party? This is the most interesting case. Obviously you want to improve your product but you have no idea how others are consuming your APIs. Legacy support is costly. In this case I think the best case scenario is that you make your intentions clear upfront. Facebook used to have a motto "move fast and break things," I agree. Software should be a continuous process and it shouldn't be too unreasonable to ask that consumers of an API keep their code up-to-date. Much like consumers they'll cost you money and debt your code if you bow to resistance. However, there is leeway here and you should check data knowing how much you could lose. Consider, if it's just a bunch of dinosaurs, you might actually be dragged down despite their currently deep pockets. Aim where you want to be in 10 years, not today. Of course you have responsibilities to give prior notice as far in advance as possible, make betas and technical preview available and work with consumers of the software. Most will be over-joyed to work with new stuff because programmers like that sort of thing, businesses may not but a software company run only by the business is probably never going to get ahead (and if your expectation of continual development is in place maybe the business folks will accommodate it as a necessary evil to them).

Here's some things of what not to do though:

-Patch Tuesday: This is dumb. A bug is a bug no matter when it happens and should be fixed immediately. It's not hard to reboot a machine and if it is that is a bug. You can do this with 0 down time and really if MS pushed companies would be incentivised to build architecture such that it happens with 0 down time. Waiting on critical issues is stupid, and companies that would maintain insecure systems because they don't know what happens when they reboot are terrible at their job.

Here's an awful ZDNET article: http://www.zdnet.com/aws-reboot-highlights-how-cloud-needs-patching-best-practices-7000034049/
Not only is letting security bugs fester not best practice but Amazon is totally in the right here. Security of their business, customers (and their customers) is more important than businesses whining because some machines are getting reset and they didn't make the effort to gracefully handle it.

-Leaving bad code in: I'd like to write another post about the absolutely awful situation about the web and blocking UI (alert, modalDialog, confirm) but nobody likes it, it's highly invasive but it's still there because nobody wants to "break the web." I can tell you if I was in charge I'd be fairly aggressive at stamping this out. Granted you don't need to kill consumers using it in a massive sweep but there are ways you can de-incentivise and eventually leave them with the choice to change or die. In the words of Batman "I won't kill you, but I don't have to save you.". At this point nothing is really being done (except the removal of the low usage showModalDialog which thankfully some Blink devs are telling enterprise complainers to STFU and write better code) so we still have very harmful features and will continue pretty much until someone makes a real move.

The need for progressive downloads

2014-09-21T21:38:00.000-07:00

I spent a few hours not too long ago trying to install OSX Mavericks. I just hadn't gotten around to using the Mac side of my computer. This process was excruciating because every time I tried to download a 5GB installer it would be corrupted and prompt me to do it again. This lead to much frustration and wasted bandwidth and I couldn't figure out what I was doing wrong. Turns out I wasn't doing anything wrong, the big file just had a chance larger than most to download incorrectly. This, to me, is crazy.

It makes sense that a large download is prone to corruption but it's amazing this is still a problem today and permeates many places. When downloading it makes sense to download chunks with a checksum and then verify it. That way I don't have to download another 5GB because something messed up. What's particularly sad here is that an app store is more or less a download manager, there's no reason it shouldn't be able to do this on it's own. Another dumb problem is if you cut the wifi, "sorry can't download, try again." I just downloaded half the file, why can't I pick back up where I left off? This is unacceptable for an app store but pretty much anywhere we should apply this tactic. Our mobile devices have unstable connections and are bandwidth limited due to cost, it's necessary for that reason alone. We shouldn't wait to verify data is good nor should we throw away good data. We should build systems that are resilient, it should work eventually, not fail and stop working and if someone wants to download a 4K movie over 56K, this should be possible, just like it should be possible to download my 8K fulldome movie over a 20Mbps connection like we have today.

Speaking of video, have you ever watched a video and refreshed the page and had to download it over again? How about buffer, skip ahead and have it rebuffer and then skip back and it buffers the part it buffered before. This is asinine and 100% of all players get it wrong. The correct behavior is to buffer from the beginning assuming I watch the whole thing in order (people like to scan videos, especially long ones they aren't invested in, but this is a safe first assumption), if I skip, hold what I had so I can still watch it without a rebuffer but start a new buffer at the new location and buffer forward. Once it hits the end, start filling in the gaps from the beginning.

Note that these interactions don't just save time and bandwidth and have a good user experience but also allows for gathering data from multiple endpoints so it can save bandwidth on the source, maintain higher speeds during network congestion or even grab data locally instead of via the internet. This is why peer-to-peer sharing has always worked like this. Why isn't this the model we always use?

Stop Using CMSs

2014-06-01T19:59:00.001-07:00

Virtually every business I've been a part of has always come up with the same idea, "what if instead of getting high-cost developers to make content changes for me, they could make a tool such that others can edit the content." In theory this is not a bad idea, unfortunately it's not quite that simple.

The first problem is that building or using CMSs is hard. CMSs naturally worm their way into codebases in an effort to control the way things are added to it. This makes it harder to do anything the CMS doesn't specifically allow. You'll spend tons of time just working around it. Easy things become hard and your perpetually stuck with something that can be next to impossible to migrate from.

Content and code aren't separable in the way CMSs typically allow. For very flat sites it might work but sites that are more application like or do things can't simply be modified without a lot of trouble. A great example is CSS. CSS has problems one of which is it's linked too strongly with content. You need to be able to change both, but CSS is also code, you shouldn't change it at the content level. But this means you need an understanding of the global style, not just a particular piece which is exactly what a CMS is trying to not have the content editor do. It's always a mess and there is no clean solution to this that I've ever seen.

CMSs are generalized and thus lead to bad performance. You need much more power to serve things in a CMS.

CMSs add complexity to the code base and thus require more environment setup and learning for new devs.

CMSs are often very expensive and from experience the expensive ones are terrible products.

Adding content is probably the easiest thing to do for a developer. A content change could take a few minutes. In fact I'm often asked to update content that's in a CMS simply because the CMS is difficult to use. The irony is that it now takes me 10 times as long to do it.

I think the main problem with CMSs is that they are a very poor way to solve a basic problem, adding content. In fact, if the content editors took a month long class on CSS and HTML and a little bit of training on the codebase you'd solve the problem in a much cleaner way. Everyone would be smarter in a useful way (not a expensive, sloppy tool usage way), the complexity is reduced, and it's super clean. The only reason I can imagine this isn't done is some people are perhaps afraid to learn a mildly technical skill. I certainly would not want someone like that working for me, this isn't rocket science.

However if you absolutely need a CMS take this advice. Use the smallest, simplest thing you can get away with. Never choose software based on extra features, only your must-have feature. Get something free and open source so it's easier to work with. Don't get a behemoth such that you have bad dependant code that requires you pay licensing for eternity. Make it service-based so you can rip it out if necessary, it shouldn't be an inseparable part of your code.

How to Find, Retain, and Keep People Doing Good Software Work

2014-05-23T06:33:00.002-07:00

At my job I do a lot of contracting so I've seen the teams and cultures of many places. It's interesting that they all have their problems, some the same and some different. Having a comparison point and being on the outside you get to see what works and what doesn't.

Do not distrust your employees or they will distrust you. This means monitoring, especially with software or scoring metrics. This stresses people and makes them uncomfortable. Employees who don't feel they can escape being watched will probably not perform as well and are less likely to trust the business. Consider, if they don't trust the business there is no incentive to do more than a minimum job and they will be less likely to make improvements.
Let employees own their own hardware. Recycled company hardware is typically old and nobody feels comfortable with it. It makes sense when an employee joins to give them the best hardware you can afford. Let them own it, they'll probably take care of it and load it up with things they feel helps their work. Also, it's hard to really divide personal and work hardware anyway. They are just as worried about you getting personal info as you are of them getting business info when they leave. If the employee doesn't work out and it hasn't been a year yet then you can repurpose it, otherwise just buy the new model. When the employee leaves let them take it after wiping it, data problems solved.
Reduce the number of people an employee has to interface with to get a job done. This means minimal IT. The biggest time waster is needing access to something and not having anyone around to grant it. Let teams select and own their products and hardware, they'll naturally pick what they think works best. It's easier to talk to a product manager than IT.
Budget for experimentation. Not all experiments are fruitful but if you outline time then people will likely take it up to learn new things and improve business practice. It's almost always a win in the end.
Budget for unit testing. It's necessary, don't think it's not as you'll be guaranteed to spend more QA time than you save dev time.
Don't even start development until the build system is in. Build systems save time and money and ensure good code. If there's crappy manual work get that done upfront because you'll soon forget, it won't be budgeted and you'll be wasting time while being able to push less code. This also reduces the risk of pushes to nothing.
Take employee feedback seriously and address it right away. Your actual workers know best what they need and want, let them have it.
Reduce management. Devs will tell you when they need BAs and project managers because they dislike doing that stuff. Otherwise let them them go with as a few people making decisions for them and let them have strong ownership of their products. The better they feel the better the work will be.

Overall this list can be summed up as follows:

Empower employees to do the best job they can. This means giving them control. They know how to do their job and what they find works best for them. Not having that control is frustrating and weakens moral, but it's also a guarantee they aren't maxing their potential.

Gesture-first symbolic alphabet

2014-05-03T13:43:00.002-07:00

It's been a long time since we really revisited the roman alphabet. Writing systems aren't really things that change too often. It's amazing to think about how much has changed since it was created and that how everything digital uses it as an assumption. Keyboards are only really a thing because people a thousands of years ago created some symbols. This creates a rather problematic experience as text cannot be communicated efficiently. This is a problem in other languages too, we actually map easy actions to letters and sometimes words creating whole translation layers to communicate on devices. I think that it would be interesting to explore creating a modern system for symbolic input based on ergonomic factors.

Of course what I think of isn't exactly like a written alphabet to translates into words or one that relates closely to speech. More like a set of symbolic gestures that translates into unique sequences. The use case I think of is web URLs. There's plenty of things one can do to cache long strings but overall it's cumbersome and the difficulty of typing actually creates additional power for those who were lucky enough or could pay for short names. But moreover, how could you input web URLs on a wristwatch. There are ideas like Minuum, but these still have limitations based on the Roman alphabet. I think what we could think of is a standard (lol) set of symbolic gestures that can allow use to input things easier to match the ergonomics of our technology.

The idea is you need a number of short, quick things that can be input with one finger. This means not requiring multiple strokes (ideally a lifted finger lift denotes completion), many direction changes or anything that would require time to differentiate. They should not be true pictographs, where they start and end and how they balance is not as important as the motion. There needs to be diversity such that things stay relatively short but doesn't get overly complex (see Chinese writing system). It would also be helpful to make these easy to recognize in software.

So a quick symbol set:

1) CW circle
2) CCW circle
3) CW double circle
4) CCW double circle
5) upward point (/\)
6) downward point (\/)
7) left point (<)
8) right point (<)
9) down line
10) up line
11) left line
12) right line
13) top-right diagonal line
14) top-left diagonal line
15) bottom-left diagonal line
16) bottom-right diagonal line
17) horizontal criss-cross (Z)
18) Vertical criss-cross (N)
19) upper-right corner (think a reversed L)
20) bottom-right corner (V mirrored L)
21) bottom-left corner (L)
22) upper-left corner (H mirrored L)
23) left curve (C)
24) top curve (V mirrored C)
25) right curve
26) bottom curve
27) left crescent
28) top crescent
29) right crescent
30) bottom crescent
31) left half-circle
32) top half-circle
33) right half-circle
34) bottom half-circle
35) inner spiral (also recognized if more than 2 turns to differentiate from circle)
36) outer spiral (also recognized if more than 2 turns)
37) left loop
38) top loop
39) right loop
40) bottom loop

It'd be nice to have another 10 for an even 50 but even then this gives much more simplicity than any current language in terms of touch input. Obviously there needs to be a symbolic representation. But with this I could essentially input types of information into something as simple as a watch and I could register a short symbol sequence for users to access my app.

We don't need to destroy what we have either, we can just build in parallel and let society decide if this is a good idea.

Font loading extension

2014-04-20T12:16:00.001-07:00

I hate webfonts. Virtually all good fonts have insane licensing terms, not only are you required by the license to use the hosts crappy CDN and are restricted from self-hosting unless you pay for premium plans but they are designed to phone home every time they are used so you can be charged per page view. This is crazy, fonts are images, who licenses a web image per view? On top of that, it punishes site users who need to make additional requests and slows the rendering of pages. I had been thinking about creating an extension that works with major font hosts to strip out the phone homing and creates a sort of cross-domain cache for certain font assets (since these requests are naturally cached separately due to a userId).

As a user I don't care about these stupid business dealings, why should I be making requests? Also, I'd love to save certain websites a bit of money by keeping the font licensing pageviews down, again because it's not my problem yet I'm forced to deal with it.

Edit: And here is a beginning which blocks some fast.fonts stuff: https://github.com/Somnid/FontBlock

It takes a network to make a network

2014-03-21T07:03:00.001-07:00

Looking into different peer-to-peer ideas one of the hardest things I've had to convince myself is that it takes a network to make a network. This sounds contradictory but it's true, at least as far as I can tell, perhaps someone wrote a fancy PhD thesis on it.

The simplest network 2 nodes and a connection between them. However, how is that connection established? If there were 2 people on Earth but opposite sides how do they know about each other? They can't. You need discovery, which is a fancy way to say "use a network to find people." You only know internet addresses because someone told you the first one. This person is part of a same network a you, maybe a more abstract personal network but a network non-the-less. Once a new peer has at least one connection then the network can function and you can do discovery within it. But you always need the outside network to become a part of the new one. This means that you are essentially seeded into at least one network from birth and from there all other contacts are discovered from that base network and others you are introduced to by other "nodes."

This is also interesting because it means that we can apply "six degrees of separation." In a pure peer-to-peer network for nearly all peers we can assume it would take less than 6 jumps to optimally send a request to someone else.

Really weird when you roll it around in your head.

Future Music software exploration

2014-03-15T22:36:00.002-07:00

Looking around it would seem like the future of digital music has none. I mean if you were making a music service or looking to improve what you have there isn't many places to go. We've moved from digital ownership to streaming "radio" lately. The radio services are actually so cheap very few people are getting paid and pretty much every big player is already jumping in and tearing apart all the startups. While I don't see this trend abating I do see ways in which one could at least create some waves before getting bought out or pushed out.

High Quality Music - I think the Pono Kickstarter is doing this and it's a good idea. They also have a triangular-shaped high-quality music player which is probably not a great idea (well it's not bad but it's going to take off but more phones and tablets should have amps and high-quality DACs). But I'd love to see music stores sell flacs of studio masters.

Sell by the Playlist - Many people make playlists, in fact it's at least as old as the mix tape. There's plenty of (bad) ways to share them online but I'd like to see options to simply buy a shared playlist. I'm reminded of YTMND which had it's own soundtrack by the community which was fantastic but it was a pirate torrent. I'd have paid the $10 or so per album if I could buy the official playlist. I suppose you could also incentivise with creator kickbacks but that has to tread carefully lest it be used for spam. All referral programs need spam flags to prevent misuse and bots.

Music API - One idea of mine was to have a collection type of service (iTunes match, Amazon Cloud Match etc) and then open the API. Either you could search if the user owned a song (and suggest it if they don't) or simply look through their library. From there you can use it. Say you had a music game, you could grab from their library of licensed music or suggest to them music that works with the application. This allows application developers to license music through users which is powerful because artists can't exempt and the heavy royalties aren't on the developer, just the user.

Just some thoughts that popped into my head. I hope some others exist but I'm not really seeing them yet.

Empower software with algorithms, not human policy

2014-03-12T20:56:00.001-07:00

There's been a lot to say lately about how the internet should be shaped. All sorts, ranging from Snowden's NSA leaks and how information is kept safe, accusations of Verizon throttling Netflix and net-neutrality, Chinese censorship, piracy, British porn filters, Tim Berners-Lee talking about a vague notion of a "internet bill of rights" etc. The thing that seem to relate them all is people don't want the internet regulated and that powers are trying to regulate at least part of it. I think this is noble goal and with this comes bad things but I think the good things about the web greatly out-weight the bad. However, where I really disagree is that anyone should be fighting with policy.

Lobbying, ISP regulation, business de-regulation and all that to me is at best pointless, a band-aid fix for a broken system. The truth is the internet is above government, it's practically unregulatable by nature. Maybe an entity with unfathomable wealth and resources could try but to me that's a bug. In software you don't mandate that users stop misusing the software, you fix it. The internet is software with a bit of hardware, if it's broken it's because one of the two is broken, the way connections are made, the way we connect, the way we organize or protect information. To fix it we make something better. It doesn't matter how much regulation, lobbying, whining and money the entertainment industry puts up, popcorn is freely open, endless copy-able and easy to use, for good or bad it's a Pandora's Box nothing can shut. If you want internet policy don't trust politicians to make it, or governments to enforce (or not enforce) it, use math, sensible algorithms that have guarantees money can't break it. Lobbying, petitions, outrage and the like I feel is not very effective. If you believe that this is important then fight human irrationality with physics, there's only one clear winner.

This applies to any future software.

JML

2014-03-10T20:26:00.002-07:00

One thing I've thought about is unifying the things we use to build on the web. Currently there are a few: HTML for markup, CSS for style, JSON for data and Javascript for logic. Obviously JSON and Javascript are close cousins, if you get Javascript you probably get JSON. That's neat, also even now things like Node.js are gaining popularity which means we're a lot closer to one language for the full stack.

But we can do better. For one HTML is still there. It's XML-based but it doesn't need to be. Realistically XML doesn't really offer much that JSON doesn't, perhaps it's easier to match ending tags but that's actually easily solvable with something like JSONA to comment it in if you want it. But overall JSON tends to be better. It's simple and it's very lightweight. If we could take HTML and convert it to a JSON schema we could reduce page overhead from less text. But what could be cooler is that Javascript works well with JSON. Using JSON would provide for easy templating since it would effectively be the same as building HTML nodes in Javascript. We could also reduce a lot of the method and properties of the HTML DOM objects because they would work with normal Javascript methods. I think there would be a lot to gain.

Here's an early shim: https://github.com/Somnid/jml

It currently creates markup that is bigger but maybe a SJON approach can get those quotes out. Also property names and nesting could be tweaked, for example a LINK tag might have it's href outside the attrs object because it's not a general attr. Obviously a lot of validation would need to happen (but JSON validation is free and easy, HTML parses do whatever quietly).

Then all we need to do is worry about CSS, but that looks surprisingly similar already...