Josh On DesignArt, Design, and Usability for Software EngineersSat May 23 2015 22:13:18 GMT+0000 (UTC)\nThe Holy Grail: Pure CSS Scrolling Tables with Fixed Headers<div class="body blocktype_body">For a recent project I needed a nice HTML table library to render a long table of data with fixed headers.&nbsp;Figuring there must be a million of such libraries, I started searching around. This would seem to be a simple thing, yet after a day of searching I still couldn’t find a good solution.&nbsp;</div><div class="body blocktype_body">There are indeed many ways make fixed headers but every method has flaws. Some require all columns to be the same width. Some don’t handle horizontal scrolling when you have lots of columns. Some use Javascript to reposition the rows instead of native scrolling.&nbsp;</div><div class="body blocktype_body">The W3C has really let us down here. Fixed headers on tabular data would seem to be an extremely common use case. I don’t understand why this isn’t just built into HTML 5. &nbsp;</div><div class="body blocktype_body"><span style="color: inherit;">So... after much research I decided to build my own system. I’ve come up with what I think is the best possible way using modern CSS standards like flex-box while keeping the markup as semantic as possible. It uses 100% native scrolling, with only a few compromises and one significant flaw. &nbsp;I’m hoping one of my intrepid readers can come up with a solution. &nbsp;</span></div><div class="body blocktype_header">Separating the Header from the Body</div><div class="body blocktype_body"><span style="color: inherit;">Getting an element to scroll is easy: put it inside a container with overflow:scroll. Getting part of it to stay fixed is not. &nbsp;I tried many ways to isolate the top row of a table but none of them work reliably (overflow, position:relative, and others). Browsers just don’t seem to like splitting a table into pieces. So the first compromise is using two tables, one for the headers and one for the body.</span></div><div class="body blocktype_body">Splitting the table half also means auto layout won’t work.&nbsp;Auto layout is when the width of a table column is based on the contents of each cell of the column. Since the table header is separate from the body any autosizing on the body won’t affect the header and the columns won’t line up.&nbsp;I think auto-layout is a bad idea anyway due to speed and non-determinism issues, so I’m okay not supporting it. We can still have different widths for each column but we must explicitly set the widths using CSS or Javascript.</div><div class="body blocktype_body">For my initial attempt I made just the body scroll and put the header above it. Using flexbox I could give the header it’s minimum required space and allocate the rest to the body. &nbsp;This is better than older solutions that give the body a fixed percentage like 90% since that will vary based on the page size. &nbsp;This solution will work, but only if the table isn’t too wide. &nbsp;If there are more columns than will fit on the page the header and body will scroll horizontally, but separately. You’ll scroll the body left and the header will stay put. &nbsp;Hmm. The opposite of progress.</div><div class="body blocktype_header">Nested Scrollpanes</div><div class="body">Then I hit on an idea: &nbsp;the header and body will stay together horizontally as long as they don’t overflow. If I put them inside a div exactly wide enough to fit them, then make that outer div scroll then it will do the right thing. the trick is getting one div to scroll only horizontally and the other to scroll only vertically. &nbsp;This is hard to explain verbally so let’s look at some markup.&nbsp;</div><div class="body blocktype_codeblock">&lt;div&nbsp;id="constrainer"&gt; <span style="color: inherit;">&nbsp; &nbsp; &lt;div&nbsp;class="scrolltable"&gt; </span><span style="color: inherit; background-color: rgb(255, 255, 204);"> &lt;table class'header'&gt;&lt;thead&gt;&lt;th&gt;foo&lt;/th&gt;&lt;th&gt;foo&lt;/th&gt;&lt;th&gt;foo&lt;/th&gt;&lt;/thead&gt;&lt;/table&gt; </span><span style="color: inherit;">&nbsp; &nbsp; &lt;div&nbsp;class="body"&gt; </span>&nbsp; &nbsp; &nbsp; &nbsp; &lt;table&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;tbody&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;tr&gt;&lt;td&gt;foo&lt;/td&gt;&lt;td&gt;foo&lt;/td&gt;&lt;td&gt;foo&lt;/td&gt;&lt;td&gt;foo&lt;/td&gt;&lt;/tr&gt; … close all the tags</div><div class="body">There is a container called <i>scrolltable</i> which contains a table called <i>header</i> with only a single row. <i>scrolltable</i> has a second child, a div called <i>body</i>, which contains the data table. &nbsp;It’s reasonably semantic and not too many extra divs.The whole thing is wrapped in another div called <i>constrainer</i>, which exists only to constrain this demo a fixed height and width. &nbsp;Constrainer is styled with:</div><div class="body blocktype_codeblock">#constrainer&nbsp;{ <span style="color: inherit;">&nbsp; &nbsp; height:&nbsp;200px; &nbsp; &nbsp; width:&nbsp;200px; }</span></div><div class="body">We want <i>scrolltable</i> to scroll only horizontally, so we can do that by setting the <i>height</i> to 100% and <i>overflow-x</i> to scroll.</div><div class="body blocktype_codeblock">.scrolltable&nbsp;{ <span style="color: inherit;"> overflow-x:&nbsp;scroll; height:&nbsp;100%; }</span></div><div class="body">We want the body to be exactly wide enough for it’s content and only scroll vertically. &nbsp;This requires the magic <i>-webkit-fit-content</i> width value, then setting <i>overflow-y</i> to scroll.</div><div class="body blocktype_codeblock">.scrolltable&nbsp;&gt;&nbsp;.body&nbsp;{ <span style="color: inherit;"> width:&nbsp;-webkit-fit-content; &nbsp; overflow-y:&nbsp;scroll; }</span></div><div class="body">I want the header to use it’s normal height and give the rest of the vertical space to the body. This sort of space allocation is perfect for flex-box.&nbsp;</div><div class="body blocktype_codeblock">.scrolltable&nbsp;{ <span style="color: inherit;"> display:&nbsp;flex; display:&nbsp;-webkit-flex; &nbsp; &nbsp;flex-direction:&nbsp;column; &nbsp; &nbsp;-webkit-flex-direction:&nbsp;column; } </span>.scrolltable&nbsp;&gt;&nbsp;.header&nbsp;{ <span style="color: inherit;">} .scrolltable&nbsp;&gt;&nbsp;.body&nbsp;{ &nbsp; flex:&nbsp;1; &nbsp; -webkit-flex:&nbsp;1; }</span></div><div class="body">We don't have to set anything on the header since the default flex value is 0.</div><div class="body">There’s only one thing left, to give the columns explicit widths.</div><div class="body blocktype_codeblock">th,&nbsp;td&nbsp;{ <span style="color: inherit;"> &nbsp; min-width:&nbsp;150px; } </span></div><div class="body blocktype_body"><br></div><div class="body blocktype_header">Live Demo</div><div class="body">Here’s what it looks like. I’ve added some visual styling to make the rows and columns prettier but these extra rules don’t affect the scrolling mechanism.</div><div class="body"><img src="/images/69761_SafariScreenSnapz059.png"></div><div class="body"><a href="">click for live demo</a></div><div class="body">Overall I’m pretty happy with it. There’s only two significant flaws: the use of a magic <i>-webkit-fit-content</i> property and the vertical scrollbar is missing. Actually, the scrollbar is there but it’s inside of the outer scrollpane so you don’t see it unless you’ve scrolled all the way the right most column. &nbsp;However, given that everyone is moving to gesture based scrolling, I think it’s a reasonable tradeoff. &nbsp;This system could be adapted to have fixed headers on the left edge instead of the top, but I can’t see a way to have both edges fixed. The W3C really should solve this properly.</div><div class="body">I've put the code on <a href="">github</a>. Please fork it and play around. Suggestions and improvements would be greatly appreciated.</div><div class="body blocktype_header">Update</div><div class="body">My friend Cooper showed me a slightly different formulation that has less boilerplate: just one div around a single table and no magic webkit properties. The downside is you have to set the width on the wrapper DIV and height on the TBODY. That's not a bad tradeoff for using only standard css rules. I've added his version to the repo too.</div>\nApple is not making a TV<div class="body blocktype_body">A year ago <a href="">I speculated </a>that Apple would never make a TV. If they ever did, I said they'd integrate a FaceTime camera with complex image processing, but I didn't think they would make a TV at all. There's just not enough opportunity in that market to make it worth Apple's while. It's low margin and no room to differentiate the product. &nbsp;</div><div class="body blocktype_body">Today The Wall Street Journal is <a href="">reporting (verge link)</a> that "Apple dropped plans to release a 4K TV over a year ago because it couldn't find compelling ways to differentiate the product.. Apple reportedly considered including a FaceTime video chat features that could direct cameras to the speaker at any given moment".</div><div class="body blocktype_body"><b>Nailed it!</b></div>\nApple Watch doesn’t need a killer app. It *is* the killer app.<div class="body">As smartwatches have slowly faded into existence from their sci-fi past, I have always wondered: <i>what is the killer app</i>? What is the feature (or actual app) that would do something <i>so useful</i> I’d wear it on my wrist, put up with a mostly-off screen and laggy voice control, learn a new interface, and charge it daily. What would it do that makes me want to actually buy one despite the limitations? &nbsp;After living with my Apple Watch for a few weeks I think I finally know. <b>The watch itself</b> is the killer app.</div><div class="body blocktype_header">The Killer App</div><div class="body">We expect platforms to have a killer app to launch them. A smartphone has tons of uses, but when Apple launched the iPhone they focused on email, iPod (playing music), phone calls, and a mobile Safari. &nbsp;Given that iPods and hand held devices that made phone calls already existed we could probably shorten this to say: &nbsp;the iPhone gives you the full Internet in your pocket. And it really did. From that base the world’s developers created many amazing things. Facebook wasn’t useful to me until I could upload a photo anytime, anywhere; but it all started with the internet in your pocket.</div><div class="body">It would be logical to assume the Apple Watch has a killer app. The iPod was the a thousand songs in your pocket. The iPhone was the internet in your pocket. The Mac was a computer that just works. What is the Apple Watch? &nbsp;At first I thought it would be notifications, which is the only thing the Apple Watch does really well right now (assuming you use an iPhone). But now I think I’ve got it wrong.</div><div class="body"><b>The Apple Watch isn’t a computer that sits on my wrist. The Apple Watch is a watch that also happens to be a computer. &nbsp;That’s a huge mental shift.</b></div><div class="body">The killer app isn’t any one feature or app. It’s that Watch is on my wrist. Always. Every day. It’s the proximity to my body -- and to my nervous system thanks to the haptic feedback -- that makes all the difference. &nbsp;A notification on my phone lock screen would seem to be the same as a notification on my wrist... but it’s not. The wrist is different. More immediate. More discreet (I always have mine set to mute). More personal.</div><div class="body blocktype_header">Daily life</div><div class="body">As always, the real test of a device is whether I use it. Have my daily habits changed? &nbsp;I think they have. &nbsp;I use the timer and alarms a lot more than I did before. When you have to wrangle a four year old kid timers really help. Having them on my wrist, and being able to set them with a voice command, makes a huge difference. Sure, I’ve been able to do that for years with my phone, but being on the wrist makes a contextual difference.</div><div class="body">After some tweaking I’ve found the notifications to be useful. Responding to my wife’s text while driving. General awareness of a Slack channel. I love going to the park with my son without having the feeling of missing something, but also without feeling like I’m always in my phone. Again, placement on the wrist is the important thing. &nbsp;Filtering the notifications is still a challenge. It will take a while before we can filter messages the way we can with spam, so I expect to see improvement from Apple on that front over time.</div><div class="body">I was surprised to find that none of the 3rd party apps have made much of a difference. I’ve searched and found nothing indispensable. The keepers, for me, have been Slack (company chat) and Things (todo list); but in both cases they are the same content as my phone, just closer. Proximity is once again the killer app.</div><div class="body blocktype_header">Should you buy an Apple Watch?</div><div class="body">So should you buy one? &nbsp;No. &nbsp;Not yet.&nbsp;</div><div class="body">I’ve spent the last few months testing lots of smart watches. Apple Watch is a definite one oh (1.0) product. It's slow and limited. As is the Zen Watch, LG Watch R, Microsoft Band, and basically everything else on the market. &nbsp;All smartwatches will get tremendously better in the next year or two.&nbsp;</div><div class="body">However, if you <i>really</i> feel compelled to buy something, then yes: buy an Apple Watch if you have an iPhone. Or a high-end Android Wear watch if you have an Android phone. But please, for the love of all things good and decent, <a href="">don’t buy a Samsung product</a>; especially the train wreck that is Tizen.</div><div class="body"><br></div>\nUnbuffering the Buffered<div class="body">I've been writing unix-ish code for more than two decades (crap, I'm old!) but last week I discovered something I'd never used before, the <a href="">stdbuf</a> command. It solves (well, works around) one of my longstanding problems working with command line programs: buffering.</div><div class="body">How many times have you been working on some code where you need to invoke a command line program. It seems so easy. You just exec the command, back-tick or spawn or whatever exec equivalent your programming language has. The result is captured back into a string that you then parse. Easy peasy.</div><div class="body">Now suppose you need to invoke a long running command line program. Perhaps it's downloading a file or you want to monitor all the processes with 'ps'. Whatever it is, you want results back from the program before it finishes. You want the output as it's generated. This seems like it would be simple. If you run it from the command line the output is incremental, often one line at a time. Now call it from your program.&nbsp;</div><div class="body">Nothing. &nbsp;</div><div class="body">No output comes into your code. Wait a few minutes. Oh there it is. The input comes in a giant chunk instead of one line at a time. What happened? Welcome to Unix.</div><div class="body blocktype_header">Everything is a file, except when it's not.</div><div>Unix' philosophy of everything is great as far as it goes, but it's actually a lie. There are many thing in unix which appear to be files but are not. Sure, you can open them like files, but they actually produce data on their own timetable. They might queue up all data until the program ends, then spit it out at once. Or they might send data in 4k chunks. However, when you run these programs interactively everything is realtime. What gives? The answer is that the standard input / output files actually have extra features to determine if the other end is 'interactive' or not. Let's dive a bit deeper.</div><div><br></div><div>When you are on the command line or terminal you are actually running what's called a pseudo-terminal. <a href="">According to Wikipedia</a> these date back at least to the late 1960s. They process control characters which move the cursor around, setting colors, resizing the screen, and other interactive things. When you run a program it receives data on the stdin (standard input) stream. If you run the program interactively then stdin comes from the shell. If you run it as part of a pipeline, or from within another program, the stdin comes from a file or some other input source.&nbsp;</div><div><br></div><div>Given that stdin could come from anywhere, how does a program know to use these interactive control characters? It turns out there are APIs to determine if the input to a program is actually an interactive terminal or really just a stream of bytes. This is how a program like Vim can be interactive through what is supposedly a file. And this is why the same program will behave differently depending on how you call it. This is why exec'ing a program from your code gives you unexpected behavior. The program is switching from interactive to streaming mode. &nbsp;</div><div><br></div><div>In Unix terminology, the output switches from unbuffered to buffered. The buffers have a default size, often 4Kb (depending on your operating system). That's why you get no output for a while then suddenly get a bunch. The buffer is only flushed when you hit 4096 bytes of data.</div><div class="blocktype_header">So what can you do about it?</div><div>In the past I've used a couple of solutions. Some programs have explicit options to turn off the buffering. This might be called <i>interactive mode</i>. Other times I can find a different way to get the data. A last resort option is to trick the program. In Node I can use the <a href="">pty</a> module to essentially create a pretend pseudo terminal (a <i>pseudo</i>-pseudo-terminal?) which then runs the app for me. It's inefficient but it gets the job done.</div><div><br></div><div>However, I've discovered a brand new solution. Or rather, a brand old one. The <i><a href="">stdbuf</a></i> command has been a part of the standard GNU utils for decades. According to the docs it will "allow one to modify the buffering operations of the three standard I/O streams associated with a program." Perfect. Just what we want. </div><div><br></div><div>It works like this. Call <i>stdbuf</i> with options to change buffering, followed by the original command you wanted to run. To disable buffering on the input stream use <i>-i 0</i>. Use <i>-o</i> for the output stream. In my case I wanted to run bluetooth scanner with buffering disabled on all of the input, output, and error streams. Here's the code in NodeJS</div><div><br></div><div class="blocktype_codeblock"><span style="color: rgb(167, 29, 93);">var</span> scanner <span style="color: rgb(167, 29, 93);">=</span> child_process.spawn( <span style="color: rgb(24, 54, 145);"> "stdbuf"</span>, //the stdbuf command [ <span style="color: rgb(24, 54, 145);"> '-i0'</span>,<span style="color: rgb(24, 54, 145);">'-o0'</span>,<span style="color: rgb(24, 54, 145);">'-e0'</span>, //disable all buffering <span style="color: rgb(24, 54, 145);"> '/usr/bin/hcitool'</span>,<span style="color: rgb(24, 54, 145);">'lescan'</span>,<span style="color: rgb(24, 54, 145);">'--duplicates' </span>//the real program I want to run ]);</div><div><br></div><div>And that's it! How does it work? Magic probably. According to <a href="">this</a> it's a LD_PRELOAD hack, which is basically magic. So there you go. </div><div><br></div><div>How have I not heard of this magic program before?!</div><div><br></div><div><br></div><div><br></div><div><br></div>\nThe Wiring of Humanity<div class="body">Today I received my Apple Watch. Compared to the three Android Wear watches and a few fitness sensors, I can safely say it’s the first smart watch that merely sucks&nbsp;instead of being truly horrible. All of these devices will continue to get better and better, longer battery life, simplified UI, etc. &nbsp;Soon we won’t know how we lived without them.&nbsp;But that’s not important right now. What’s important is when we look back in history we will say 2015 is the day we started to wire up humanity.</div><div class="body">Try to imagine the world one hundred years from now. It’s really hard. &nbsp;Predicting even 20 years in the future is a crap shoot. &nbsp;In a hundred years we’ll have cheap space flight and cheap power. Unlimited food and objects thanks to advanced bio-farming and 3d printers. Day to day living has been&nbsp;rewired around the self driving car. We finally cleaned up the atmosphere and started bringing some extinct species back to life. The average person&nbsp;is effectively&nbsp;infinitely wealthy by today’s standards. In short, minus the warp drive, we live in Star Trek.</div><div class="body">It’s an idillic vision. While I have undoubtedly gotten details and timelines wrong (self driving cars are coming much sooner that I expected), I think the core is correct. Pretty much any physical problem has been solved or is at least solvable. That doesn’t mean we have world peace, however. &nbsp;People are&nbsp;still people&nbsp;so people&nbsp;problems will remain. &nbsp;Unless something else changes.</div><div class="body">The&nbsp;smart watch is the first computer that is on you 24/7, or at least the waking part of your life (why don’t we have&nbsp;body heat&nbsp;charging yet?). This is powerful. Eventually the devices will disappear into an earbud or an implant. Humans will be connected to the global network and each other in a far more intimate way than ever&nbsp;possible.</div><div class="body">Today I can know my wife’s location at any time, and she can know mine. &nbsp;I can instantly take photos of my son&nbsp;doing something cute&nbsp;and share them with my mother 2500 miles away. Instantly. For free (marginal cost, anyway). I can tweet my immediate thoughts to anyone who cares to know them, instantly, for free. &nbsp;Smartphones and Twitter didn’t exist a decade ago. Now imagine a hundred more years of progress.&nbsp; </div><div class="body">I know. You can’t.&nbsp;It’s fairly impossible to imagine life after being connected to the cloud brain for a century. But one thing is for sure. Anyone will be able to know what anyone else is&nbsp;doing or thinking at any time, if they simply choose to. &nbsp;This is a fundamental change in humanity. We all become wired together. &nbsp;We become, in essence, a planet of telepaths.</div><div class="body">Does this blown your mind? It certainly blows mine. &nbsp;I don’t know what the future holds but the potential&nbsp;is literally mind boggling. Will we be&nbsp;happy telepaths like the Betazeds? Will we hate&nbsp;each other and long for isolation? What social norms must we develop to protect our sanity? How will we balance physical relationships with the virtual ones? Perhaps all travel will end as we experience everyone and everything remotely&nbsp;and instantly.</div><div class="body">I only know one thing. It’s going to be a helluva a ride.</div>\nSamsung Should be Broken Up, I Have the Evidence<div class="body">As part of my research at Nokia I often test and analyze products from other companies. This gives us an awareness of the state of the industry, and helps us to focus our efforts. This week my target was the Samsung Gear S smartwatch. As of yet I have been unable to actually test it. This is my story. And the story of why Samsung should be broken up into smaller companies that can actually make good products.</div><div class="body">When my Gear S arrived I immediately noticed the classy two part box, very much like the boxes my traditional watches come in (I refuse to call them <i>dumb watches</i>). My high hopes were about to be dashed. While I knew the watch would require pairing to a phone before being usable, I assumed it would work with any Android phone. After all, why restrict your market, right? I was wrong.</div><div class="body">A quick search on the web turns up that the Gear S, uses Tizen, not Android Wear. For some reason all of Samsung's Tizen watches only work with Samsung devices. The watches require a minimum OS version and also the Samsung Gear Manager app. This app is only available through Samsung's own app store, not the regular one, and it refused to install on my Moto X. </div><div class="body">Okay fine. Samsung wants you to use their watch with one of their devices. I think it's foolish to restrict your market, but I'll live with it. So I go to Costco to pick up a new Samsung tablet. In this case, the 8 inch Tab 4 (not to be called the Tab 4 8, which would make no sense). I forget if the tablet had Galaxy in the name.</div><div class="body">After charging and boot the tablet I ran all of the software updates. Hmm. No Lollipop. Why is a brand new device not receiving the latest OS? No matter, the Gear Manager app works on KitKat. I dutifully go to Samsung's ugly app store and install the manager. Turn on the watch to pair, and.... nothing. The tablet can't find it. After messing with settings, checking bluetooth, etc. I waste 30 minutes and still Samsung's own app can't see the watch. Getting a bit frustrated here.</div><div class="body">After some Googling I scan for the watch from regular Bluetooth settings. It sees the watch! Finally some progress. Select it. And... it takes me right back to the manager app that couldn't find it a second ago. Except this time it says that the watch isn't supported on my device or requires a software update. It doesn't tell me if a software update is available, or what version I would need. And of course, it didn't give me this message when I first scanned, thus wasting my time.</div><div class="body"><b>What devices actually work?</b></div><div class="body">Now it's time to answer the question. What devices are actually supported by the Samsung Gear S? Search around for it. I dare you. You won't find the answer from Samsung. Let me help you. Here's Samsung's <a href="">support page for the Gear S</a>.</div><div class="body">In their own words: <i style="color: inherit;">Samsung Gear S™ is currently compatible with Samsung devices that meet the following criteria: </i><span style="color: inherit;"><i>Android™ version 4.3 (Jelly Bean) or higher, WVGA or higher screen resolution, and 1.5GB or higher memory.</i> My Tab 4 8 certainly meets those requirements, though I have no idea why a watch manager app needs a <i><b>gig and a half</b>&nbsp;</i>of memory to run, but still, it should work. </span></div><div class="body">Further search reveals a list of Samsung phones on AT&amp;T's site which support the Gear S, but of course they only list the phones that AT&amp;T sells. The same for T-Mobile and other carriers. Why can't I just get a full list of compatible devices from Samsung?</div><div class="body">I finally get the answer from an <a href=";ASIN=B00PMABICC&amp;nodeID=2335752011&amp;store=wireless">Amazon review</a>. Apparently the Gear S only works with <i>specific</i> Samsung phones. Not any of Samsung's tablets. Not any one else's phones. Not even all Samsung phones. Just specific ones that no one has a complete list of. The bottom of the Gear S support page even says: "<i>Some Samsung Health/Fitness applications and related services available for Samsung wearable devices may not be compatible with Samsung tablet devices"</i>, which implies that the rest of the tablet experience would be fine. That is clearly not the case.</div><div class="body">Today I returned the Galaxy Tab48 to Costco and ordered a Samsung Galaxy S5 from Amazon. Not an Active or Alpha or Mega because who knows if the same phone in a different body would work. Just a plain S5. Hopefully my color choice won't affect the compatibility rating.</div><div class="body">This is a truly horrible experience for the customer. I'm literally being paid to use it and I already hate it. I would never recommend anyone get a Samsung wearable.</div><div class="body"><b>Too Many Devices</b></div><div class="body">Samsung products have become confusing. Look at their lineup. Can you tell me which one to buy? Why do they have both a 7" and 8" Tab 4? At least call it the Tab 4 + so that you don't confuse the numbers. Their phones are worse. What's the difference between an S5, Alpha, Mega, and Active? They look roughly the same but with wildly different prices and support. Is the Note a tablet sized phone or a phone sized tablet? I didn't know without looking up the specs (apparently it's a huge ass phone with a stylus).</div><div class="body">Once you get a device from them the OS updates are spotty. Why do some devices receive updates and not others? Why does a brand new device run an old OS, with no timeline for an update? Why does their manager app refuse to run on a device which meets it's own <i>documented</i> specs? &nbsp;</div><div class="body">And why can't a tablet work with a smartwatch anyway? It has bluetooth and wifi. It has the horsepower and hardware. There is no technical reason why this shouldn't work. Did they intentionally exclude tablets or were they too lazy to certify the devices from other branch of the company?</div><div class="body"><b>So how did this happen?</b></div><div class="body">It's worth stepping back to ask the question: h<span style="color: inherit;">ow did Samsung get like this? How does one of the biggest companies in the world fail so badly at making good products? This isn't just the product itself that failed, but the advertising and documentation and marketing around the product, and the massive over-abundance of product <i>choices</i>. I think I know the answer.</span></div><div class="body"><span style="color: inherit;">Samsung’s mobile division&nbsp;is a huge&nbsp;company in it’s own right.&nbsp; They make a lot of products, many in overlapping categories. Samsung wants to over-saturate every possible part of the market. They want to use all of the new components coming out of the rest of Samsung. They also have a lot of people to employ, so they have them make what are essentially duplicated products. These products don't exist because of market demand. <i>They exist because Samsung needs them to exist</i>.</span><span style="color: inherit; font-size: 26px;">&nbsp;</span></div><div class="body"><span style="color: inherit;">I suspect that Samsung, like many big tech companies, is full of silos. These are product groups who don't talk to each other. They may even compete with each other.&nbsp;The silos focus only on what’s next, never on where they are now (thank you Yoda). &nbsp;Once a device leaves the factory they don’t want to ever think about it again. They don’t wan’t to update its software. They don’t want to confirm whether it will work with anything newer. &nbsp;They don’t want to certify it with a product from another silo unless forced to by upper management. </span></div><div class="body"><span style="color: inherit;">The problem is that when you forget about the device you are also forgetting about your customer. &nbsp;I've been burned. I will never buy another Samsung device again. They simply didn't care enough to </span><i style="color: inherit;">correctly</i><span style="color: inherit;"> document basic requirements. Was it the phone group's responsibility to document the compatibility list or the watch group? How do I know my next phone won’t work with my current Gear watch? Perhaps the watch group will have moved on to the new watch and the phone group to the new phone, and I'm left without an update.&nbsp; The customer experience, which goes beyond the time of purchase, should always be first. </span>It seems that what comes first at Samsung is p<span style="color: inherit;">umping out new devices.</span></div><div class="body"><b>Nuke it from orbit. It's the only way to be sure.</b></div><div class="body"><span style="color: inherit;">The only way this can be fixed is by making Samsung smaller; by taking away the conflicts of interest and silos.&nbsp;</span></div><div class="body"><span style="color: inherit;">Samsung should spin out the mobile and gear divisions into their own companies.The Gear division would make watches that work with everyone's phones and tablets. They would finally have an incentive to do so because they could sell more watches. No longer would&nbsp;they be held back by a <a href="">strategy tax</a>.</span></div><div class="body"><span style="color: inherit;">The mobile division could then make fewer but better phones that people actually want to buy with less overlap. They would no longer have to pump out every variation just to use up components from Samsung's semi-conductor division Samsung should be broken up.&nbsp;&nbsp;</span></div><div class="body"><span style="color: inherit;">Of course they won’t do that. Instead they will amble along making a lot of revenue and very little profit, pushing out the latest specs in crappy products with unhappy customers. Customers who will abandon Samsung when given the choice.&nbsp;</span></div><div class="body"><span style="color: inherit;"><b>Samsung: too big&nbsp;to fail, too big to succeed.</b></span></div>\nPredicting the future is hard<div class="body">Smartwatches are coming. By Christmas they will be everywhere. And we won't know how we ever lived without them. Or so we are told to believe. But if you were a company making a smartwatch, how would you know what features to build? How would you know which features will fit the "something people didn't know they wanted" category? You have to predict the future. Turns out, that's hard.</div><div class="body">I'm doing a lot of wearables research right now for work. It got me thinking. How do successful companies like Apple make things that people didn't know they wanted? Certainly they take risks, and occasionally the risk fails (iPod HiFi, anyone), but most of the time they nail it. How do you do this?&nbsp;How do you predict what features will make someone want to use a device. How did Apple know that people wanted&nbsp;iPods before iPods were on the market. How do we know that people will want to move notifications from their phone to their watch, and that this is valuable enough to justify a multi-hundred dollar device.</div><div class="body">The first strategy is to build a feature that is obvious and simply do a really good job of it. Lots of companies are trying this. Fitness tracking and notifications are two obvious features. This is why s<span style="color: inherit;">mart watch coverage focuses on those features. They&nbsp;are known problems that we can already solve (though perhaps not solve well, yet). These features are also valuable enough that there are also standalone devices which do just one or the other of these things.&nbsp;</span></div><div class="body">But this doesn’t answer the question of what will be the other killer features. Fitness bands are fixed function devices that will only ever do one thing well. Apple Watch and Android Wear are app platforms. They are built to expand and grow over time. The only reason to build such as system is for future features that we can't predict yet? What will be the killer apps? How do we predict the future?</div><div class="body">The answer is we can’t. &nbsp;Before these things are built we simply can’t know what will be good and useful, or bad and useless. We can make some educated guesses based on what are known problems, or existing solutions that we hope to replace, but until we <i>actually</i> build&nbsp;it we never really know.&nbsp;</div><div class="body">So&nbsp;build it we must. &nbsp;I’m pretty sure this is what Apple does. They prototype things internally. Lots of things. Crazy things that will probably never ship. (Just look at some of their insane patents). Apple knows that only 1 out of 10 will be a good product idea, but they don’t know which one of the ten until they try them all. &nbsp;You’ve just got to build it.</div><div class="body">So, we have to build it. I don’t know what will be the killer apps in a few years that justify the wide spread adoption of smart watches. The only way to know is to build it.</div><div class="body">Alan Kay famously said in 1971: "<i>The best way to predict the future is to invent it.</i>" He's still right<span style="color: rgb(37, 37, 37);"><span style="font-size: 14px;">.</span></span></div><div><br></div>\nSmart Watches: The Best Interaction is No Interaction<i>Note: The first half of this post was written before the Apple Watch event and the second half after. I wanted to capture my thoughts before they were polluted by endless "reviewers" proclaiming the genius/delusion of Tim Cook. I almost didn’t want to write this because I knew my conclusion would be that you can’t review any technology this personal without using it for a while, and here I am reviewing a device I haven’t personally used. That said, I think this represents more of my thoughts on the category rather than Apple Watch in particular, a category that is going to bigger than we expect. So... here goes.</i> <p> </p> <p> </p> <h3 id="id49550">In the Beginning</h3> <p> On the eve of Apple’s watch event I'm trying to collect my thoughts about smartwatches. I’ve used smart watches before and recently purchased <a href=''>one of the best Android Wear devices</a>. My general impressions for the category aren’t great, but the potential is huge. Let’s dig in. </p> <p> </p> <p> A few initial thoughts: </p> <p> Round watches look really cool but they just don't feel practical. I find them hard to navigate. My fingers keep wanting more horizontal room. Actually, you <i>could</i> design a great interface for circular watches that take advantage of the round shape, but it would be completely different from the rectangular UI. (remember the iPod?). Trying to make both shapes with the same software is a mistake on Google’s part. Pick one shape and stick with it. </p> <p> It’s hard to evaluate the interface from descriptions and screenshots, or even animations. With a screen this small every tiny detail matters; minimalism to the max. The only way to evaluate is to use the device for a while. A long while. Like, a week or more. Keep that in mind when you read all of the "reviews" of the Apple watch this week. </p> <p> The most useful indicator from a watch is actually the buzzer. <i>(Hmm: Note to self. What about a screen-less watch? Vibrations as the only output? You can actually do a lot that way. Have to come back to that.)</i> </p> <p> Battery life isn’t as big an issue as I feared. Bluetooth LE is pretty damn good these days. While Pebble’s week of battery is pretty awesome, most people just need it to go a single day and recharge thoughtlessly on the bedside table. The future of power management isn’t going to be better batteries, but better chargers. Oh <a href=''>Touchstone dock</a>, how I miss you. </p> <p> Still, why would someone want one of these things? With a starting price of several hundred dollars and dubious ‘fitness’ benefits, why should the non-early adopter buy one of these? For now the answer is: they shouldn’t. But that will change; and probably faster than we (the techies) realize. </p> <p> </p> <h3 id="id66720">The Killer App</h3> <p> Smartwatches still lack the killer app. That’s okay. Smartphones really didn’t have a killer app at first either. Arguably the first killer app for smartphones was Mobile Safari, but that was just a portal to the many things on the web, not an app in itself. In a sense, good network access on the go was the killer app. There wasn't one particular task that made smartphones amazing at first. </p> <p> After a decade of smartphones we realize there isn’t a single killer app. There are <b>tons</b>; and what is killer for you is unnecessary for someone else. It took building a rich ecosystem of 3rd party apps for the true value of a smartphone to be realized. I use at least ten apps multiple times a day on my phone, and only the alarm clock and Safari are built in. The rest were built after the iPhone existed. </p> <p> And so it will be with the smart watch. <b>The exciting things won’t be what we see today, but what we will see in a year, or five years.</b> The little things that make your life better. The little ways they connect with the other digital (and non-digital) objects in your life. These are the features we simply can’t predict today. Even Apple can’t. But when they arrive, watch out. </p> <p> The smartwatches I’ve used are clunky, large, have poor battery life, and are still too confusing; but make no mistake: when it works, it’s magic. All the pieces of your digital life in sync. </p> <p> Example: my wife texted me while I was driving. I glanced, made a quick swipe, spoke a reply, and it was sent. No extra buttons. Simply magic. For a moment I was living in the future. This is what Apple is promising. Making your life magic. </p> <p> A smartwatch isn’t really a device, it’s an extension of your smartphone, or more properly an extension of the smart ecosystem you are a part of. (If Google ever does support Android Wear on iOS I expect it will be a pale shadow of the Android experience). The watch is at it’s best when it leverages that ecosystem. All of the information already present on your phone and the cloud, working on your behalf. When it works together, it’s bloody magic. (Perhaps that's why we find iCloud's bugginess so frustrating). </p> <p> Today, our smartwatches will not be magic all the time. Voice recognition is heavily cloud dependent. Google does an amazing job of making it fast but any latency on a watch breaks the illusion. Even the best smart watch can become frustrating fast. Apple’s ads make Siri look practically instantaneous but I want to see what it will be like under real world conditions. </p> <p> Smartwatches will (are?) result in a flurry of notifications. Both Apple and Google have made recent changes to their respective operating systems to better manage alerts, but it’s still going to grow out of hand. We may need to start applying spam-filter like technology to the problem. It’s really a catch 22. Notifications make the watch worth while, but too many makes it a pain to use. Finding that balance, and adjusting it for every person without being a rules programmer is going to be very tricky </p> <p> </p> <h3 id="id58377">Is it worth it?</h3> <p> </p> <p> The final question I hear from lots of people: is it worth getting a smartwatch which simply moves the notifications from your phone screen to your wrist? Aren’t we simply saving 10 seconds of time to remove the phone from your pocket? The answer is yes and yes. </p> <p> Yes, it’s totally worth moving the interface closer. It’s not just 10 seconds of time. This is a case where a quantitative difference becomes <i>qualitative</i>. An interaction that takes one second on your wrist really is different than the 10 seconds from your jeans pocket. It fits under a threshold that allows you to continue with your current frame of mind. It doesn’t break your concentration. It lets your short term memory remain undisturbed. It really is different. </p> <p> ...provided of course, that the notifications are minimal and can be immediately ignored or acted on quickly. Interaction design is far more critical, and difficult, on a wearable device than a phone. These apps are going to be a <b>lot</b> harder to build. Making apps for wearables is as different from phones as phones were from desktops. Perhaps this is why the Android Wear store is 90% ugly watch faces. I worry about a flood of crappy watch apps that give the field a bad name. Perhaps this is why Apple is so far being conservative on that front. Hopefully they apply stronger design filters in the Watch App Store. </p> <p> </p> <h3 id="id37136">The Best Interaction is No Interaction</h3> <p> The best interactions will be no interaction; things that happen automatically on your behalf, with a gentle notification that it happened. This will be <a href=''>Calm Technology</a> at it's best. Your watch as presence indicator. Unlock your phone automatically. Unlock your car or house (when it recognizes your heartbeat signature to ensure it’s really you). Remember where you parked your car, automatically. Warn you when you leave a phone in a bar. Buzz you when it’s time to stretch, or drink some water, or leave early for a meeting because of traffic. <b>Smartwatches will be less a device than a guardian angel, doing things on your behalf.</b> This is, of course, terrifying. </p> <p> Terrifying not because of automation, but because of how much of our lives may be controlled by just two companies. I'm afraid I don't have an answer for that. The robots taking over might be nicer. </p> <p> </p> <p> </p> <p> </p> <h3 id="id95184">After the Apple Event.</h3> <p> It's now Friday. I finally had a chance to watch the Apple event and my opinions haven’t changed much. The watch's interface is clearly more polished than what we saw last fall; and I really, really want the new MacBook. </p> <p> So bearing in mind that I can’t judge a wearable I haven’t used, here is my judgement on a wearable I haven’t used. </p> <p> </p> <ul><li>I really like the new scrollbar design that’s more indicative of where you are in the dock. Please bring that back to OSX.</li> <li>I have doubts about voice quality, but accepting a phone call on your wrist will be awesome when you are holding a 3 yr old.</li> <li>The navigation feels more refined than Android wear, but still tricky. I really want to see how it works in person. it’s not clear what actions you do with the digital crown and what uses swiping. Some gestures seem to be overloaded. This is the most difficult part to design and really must be judged in person.</li> <li>The health aspects don’t seem much beyond what I can get out of other health trackers. The key will be filtering this into actionable data. That will require better 3rd party apps.</li> <li>The app constellation is still chaos.</li> </ul> <p> </p> <p> Digital Touch is the most fascinating part to me. Nothing else (mainstream) does that right now. It really sells the vision that these are personal devices in a way we've never had before. People want to communicate with their loved ones. It’s what separates us from the animals (<a href=''>except the weasel</a>). </p> <p> Quick anecdote. I saw paired cylinders when I was an intern at Xerox PARC in the mid-90s. When you rolled one cylinder it’s match would move in tandem. The idea is that you could bring this with you while traveling and give the occasional gesture to your partner to let them know you were thinking about them. Digital Touch is clearly the modern equivalent. </p> <p> </p> <p> So, will I get one of these? Of course, I’ll get several. That’s my job. The interesting question is whether my my non-tech wife or mother want one. I think so. By Christmas there will be actually useful apps and a slew of bug fixes. This will provide real value in a way that can’t be quantified by a spec sheet. Value in the form of feeling and subtle interactions. </p> <p> Welcome to the new personal computer. </p>\nThreeJS Cookbook ReviewAmong the too many things I’ve done recently, I was a tech reviewer for a new WebGL book from Packt author Jos Dirksen called the <a href=' '>Three.js Cookbook</a>. <p> </p> <p> </p> <p> <a href=''>WebGL</a> is an amazing technology. You can build 3D graphics and animation that run blindingly fast on desktop and mobile. Even <a href=''>iPhones</a> support it now. There’s just one downside: WebGL is complicated. </p> <p> WebGL is basically OpenGL ES 2 for the web. If you’ve done any OpenGL work before you know it’s very low level and requires a pretty extensive background in 3D graphics and matrix math. While I prefer JavaScript to C++, straight OpenGL is still pretty hard. That’s why most people use a library, like ThreeJS. </p> <p> <a href=''>ThreeJS</a> is probably the most popular open source WebGL library, though there are <a href=''>plenty</a> of <a href=''>others</a>. Of course ThreeJS is still fairly complex itself. It's the nature of the beast. If you just want to do one specific thing, like load up a model and light it, learning all of ThreeJS is overkill. That’s when you want the ThreeJS Cookbook. </p> <p> The Cookbook has over 80 recipes all structured the same way: what you’ll learn, what you’ll need, how to do it, and how it works. Get in and out quickly. Don’t think the fast nature means it’s not comprehensive, though. It covers pretty much everything from lighting and model loading to height maps, point clouds, and event custom shaders. And of course all example code is in a <a href=''>github repo</a>. </p> <p> </p> <p> </p> <p> I happily recommend it. </p> <p> The Three.js Cookbook: Now available from <a href=''>Packt</a> or <a href=''>Amazon</a>. </p> <p> </p> <p> <img src='' alt='text'/> </p>\nAmino RefactoredI've done a major refactoring which will make <a href=''>Amino</a> easier to install, easier to maintain and, eventually, better performance and portability. Part of this work involved moving the platform specific parts to their own node modules. This means you should <b>no longer install aminogfx</b> directly. Instead, install the appropriate platform specific module. Currently there is one for GL and one for Canvas. I've also added stage transparency support to Raspberry Pi! <p> Here's how it works on the Pi. </p> <p> Install NodeJS if you don't already have it installed. You'll also need GCC for the native bits. Then, inside your app directory, install <b>aminogfx-gl</b> </p> <pre><code>npm install --save aminogfx-gl</code></pre> <p> Then wait while it downloads and compiles everything. This may take a while. It's about 5 min on my new Raspberry Pi 2. It'll take a bit longer on the Pi 1. </p> <p> </p> <p> In your app, require aminogfx-gl then code as normal. The code below creates a window with a rectangle and circle. </p> <pre><code>var amino = require('aminogfx-gl'); amino.start(function(core, stage) { stage.fill("#00ff00"); stage.opacity(1.0); var root = new amino.Group(); stage.setRoot(root); var rect = new amino.Rect() .w(200).h(250).x(0).y(0) .fill("#0000ff"); root.add(rect); var circle = new amino.Circle().radius(50) .fill('#ffcccc').filled(true) .x(100).y(100); root.add(circle); });</code></pre> <p> New to this version are the stage.fill and stage.opacity properties. Fill controls the background of the window, black by default. Opacity affects the opacity of the window's background. If you set it to 0.0 then the background will go away completely. On the Mac this will have no effect: </p> <p> <img src='' alt='text'/> </p> <p> but on the Raspberry Pi, this will let what's behind show through. This could be the console, or another app, or a video. </p> <p> <img src='' alt='text'/> </p> <p> Layering multiple apps together opens up a lot of interesting possibilities. I can't wait to see what you make with it. </p> <p> </p> <p> Though there are multiple github repos now, one for each backend, most of the code is still shared in the <a href=''>aminogfx repo</a> repo. Use that for docs, bugs and <a href=''>feature requests</a>. </p>