Far reaching impacts of 3D printing

Over the past few days I’ve seen a couple of articles relating to 3D printing which in turn amazed and shocked me. These articles discussed; how a patient had 3/4 of their skull replaced with a 3D printed version (presumably for good medical reason), and that a license had been issued to a company who are intending to 3D-print a gun (apparently the debates about this are well known, but it was news to me).

The ability to cheaply and easily create any object will introduce some interesting new challenges for large and small industries. In the next couple of years I’m sure it is going to become commonplace to print 3D objects in the home.

Right now it’s a geeky thing, for the very early adopters with high disposable incomes, but if you use the inkjet printer as a starting point, it’s easy to imagine in a few years from now seeing a battered multi-purpose scanner/photocopier/inkjet/3D printer discarded by the side of the street with a sticker on it saying “Take me. I work. Need ink and thermoplastic”.

To illustrate the potential issues, let’s take an example that is close to (my) home … Let’s say I 3D print a part of a Lego™ mini-figure, because Luke Skywalker’s head went missing under the bed somewhere. Clearly, this is a copyright infringement and Lego™ of Denmark should be worried. Suddenly their Intellectual Property  is not only leaking through the mass production markets who are well known for making copies of copyrighted things (you know who you are), it’s also leaking in a thousand different anonymous households around the world.

Based on the experience seen in some other industries, where there have been attempts to limit this IP leakage by restricting the features of hardware – think region control for DVD’s and the original iTunes with restrictions on the number of downloads and devices (known as Digital Rights Management)- is it possible that larger manufacturers could conspire to impose controls over the capabilities of the 3D printers themselves ? Built in copy-locking, a mechanism that automatically applies a charge for certain objects, and an inability for the printer to replicate a non-locked version of itself could be some functions mandated.

How about if each 3D printer was rendered incapable of printing something deemed undesirable such as guns, ammunition, drugs, body parts …

This sounds incredibly difficult to achieve, and would raise many ethical issues, but I can definitely imagine this being conceived and maybe happening.

It is also possible that some companies will see this as an opportunity to publish their product designs, charging a licence fee for  use, thereby increasing the penetration of their product into the market, and reducing their cost to manufacture and distribute.

Maybe product designers and the manufacturing industry are just about to get the thrashing that the music industry has had – where the value of a bit of unique IP (Music) is diluted so much that the original creator never sees much reward at all.

Advertisement
Tagged , ,

3 and 4 in a series on HTML5 for the enterprise

Continuing the story on HTML5 and why it’s ‘good enough’ for enterprise, here are two more commonly heard assumptions regarding building a web app using HTML5.

The current HTML5 ecosystem is by no means perfect, but it is very good for some things. The current draw backs in user experience and browser and device ubiquity probably just don’t matter for Enterprises, who are for the most part IT driven and uncomfortable thinking about visual design and User Experience as part of a system design.

3 – HTML5 development is cheap – ’cause it’s the web, right ?

There’s no doubt that the design and development skills needed to build HTML (and the absolutely necessary Javascript and CSS) are readily available, and the development tools are mature and sophisticated. However, my own experience has been that :

  • Because HTML5 is an evolution from HTML4 and other associated technologies, it is fairly easy for any web designer or developer to claim some HTML5 skills.  While HTML5 is not a hugh leap from HTML4 or XHTML, it does have nuances and a very heavy reliance on CSS3 and Javascript.
  • CSS3 skills can be in something of a no-mans-land between visual design and development. A good all rounder web generalist is more likely to be comfortable with CSS3 than a dedicated designer or dev.
  • Javascript is becoming more and more arcane as a plethora of frameworks and add-on libraries and languages sprout up, in an attempt to rationalise and simplify the use of the language which is now expected to be enterprise-grade. In fact these are having the effect of making the development ecosystem more and more complex.

Add to this that few people are really familiar with Responsive Design (so it has to be learnt), + time overheads to cater for the vagaries of each browser and device, and suddenly things are not looking quite so cheap and straightforward.

4 – Developers will desert native apps in favour of HTML5 (because it’s cool)

Development using native technologies for iOS and Android have become a huge success story for Apple and Google and also for the developers who actually build the applications that fill iTunes and Google Play. While Apple and Google take 30% of the sale of any application (for providing a consumer billing platform and app store as a distribution point to the market), the remaining 70% goes into the pocket of the developer. Build a successful app and you could be rich.

The fact that there is money to be made from native apps development is something that the HTML5 lobby continually ignore – vaguely hoping that because HTML5 is a new, cool, thing developers will realise its the future and just slowly move across to it as demand from consumers increases.

Unfortunately, there are some things that will need to be in place before there is an easy way for a developer to charge for their work and an easy way to be found by potential customers. Some native devs are indeed now saying that it is getting difficult to be found in the iTunes app store and Google Play due to overcrowding – but where would they rather be ? Out on the web trying to drive traffic to their web-app with SEO and charging customers via Paypal … ? I’m not so sure.

More to come soon.

First two in a series of HTML5 expectations

The first couple of expectations and assumptions regarding HTML5. Please let me have your comments and see whether these ring true …

1 – HTML5 works the same in all browsers

HTML5 is not yet a ratified W3C standard, however each of the major browsers already have support for the bulk of HTML5’s features. There are plenty of compatibility matrixes available if you need to find out what works where (here’s one at Wikipedia), so I’m not going to worry about that here. However HTML5 compatibility only describes (approximately) one third of the whole picture of what needs to be built. Javascript and CSS3 are the two other cornerstones of the technologies needed to build a modern web interface*, and both of these have their own varying levels of support in the major browsers, complicating things further. So, if you want to build one web site that works in several browsers, there are two possible approaches :

  1. Cut the features of the web site to a bare minimum so that what you build uses only the generally supported features of HTML5/Javascript/CSS3 that work in all browsers. This will result in something that looks very generic/plain/old-fashioned (take your pick) but will probably do the job from a functional point of view.
  2. Plan to allow your designers and developers an extra 10%-15% for every additional browser that you add to the list to be supported. They will spend this time working around different features and variations in the HTML5/Javascript/CSS3 support for each browser.

Alternatively if cross-browser support is less important you could target a single browser, or choose a couple which are widely used across your target user base. Chrome and Firefox might be the two, Opera could be a consideration, Safari if you have Mac users, while Internet Explorer – in any incarnation  still considered something of an outsider – will probably pickup with the spread of Windows 8 and IE 10.

There’s a great score card for all browsers here, showing that Maxthon 4 is the winner in the HTML5 stakes right now (and I’ve got to admit I’ve never heard of it)

*There are several other lesser-used technologies included and referenced by HTML5, such as SVG, MathML, Ruby …

2 – HTML5 works the same on all devices

A common statement from a client who is looking to build an app or web-app is

“We only want to build one thing, and we want it to work the same on everything”

This question is driven from the clients (usually anecdotal) understanding that native apps need to be written explicitly for a given single device, and the following expectation that simply building it in HTML(5) will magically make it work on everything, everywhere.

If you think about it for a moment, it’s actually a big ask for a web page (and all of its embedded media and images) that are designed for a 15″ screen to shrink down to a 2.5″ screen, and every other screen size in between, without some serious considerations about the effect on the usability and features per device, not to mention the fact that the smartphone user almost definitely wants different things from a website when they are walking around town vs. in front of their laptop in the office, and would want a different experience again on their web TV.

A simple way to think about this usability difference per-device is to consider ‘hover’; A common bit of design fluff is that some parts of a web page change when you hover your mouse pointer over them – maybe the colour changes or something animates …

Now think about how hover works on a tablet – that’s right, there’s no mouse pointer and no hovering – when your finger is not on the screen, the browser doesn’t know where it is – therefore your designers and developers need to cater for this when building the web app. Either they don’t use ‘hover’ at all for any device, or you design and code to cater for the devices where the concept of ‘hover’ exists, and those where it doesn’t.

The current answer to the most obvious of device differences – screen size – is known as Responsive Design, which is a way of scaling a given page up and down so it is fit for the size of the screen on the device. Responsive Design is a great idea, and can work really well, but it involves a lot of complex design decisions (per device-size) up-front, followed by a highly complex HTML5/Javascript/CSS3 coding exercise. Of course, frameworks and tools are springing up to meet this complexity, but be prepared for 5x effort when building for responsive design vs. a single device and browser.

More to come on this topic over the next few days.

Just enough is good enough for Enterprise mobility

Over the next few days I’ll be writing about HTML5 – what it is, and is not, and why some of the issues it faces are irrelevant for Business and Enterprise.

HTML5 has a lot riding on its shoulders, and there are many misconceptions about what it can and cannot do, and why you’d choose to use it as a technology. There are many things that, as of this writing, just don’t completely work. For the most part, these flaws are well known and will probably be fixed in time by the various browsers but there are other problems of expectation that are not really technology problems, so won’t be fixed as such.

The common expectations are that :

  1. HTML5 works the same in all browsers
  2. HTML5 works the same on all devices
  3. HTML5 development is cheap – ’cause it’s the web, right ?
  4. An HTML5 web app can do everything a native app can
  5. Instant updates are better than software upgrades
  6. Developers will eventually flock to HTML5, leaving native apps behind
  7. Hybrid apps will solve HTML5’s deficiencies

What I’ll be attempting to explain in the posts to follow :

  • The ins-and-outs of these expectations
  • Why none of the above actually matter for an Enterprise application
  • What does matter for an Enterprise considering a mobile application

First post in this series, addressing points 1 and 2 is now available

 

Native apps in their infancy

In the face of the popular, simplified, ideas about HTML5 as the saviour of mobile development, it is begininning to feel hard to defend the definitely old-school-style of native development for iOS and Android.

The steps in development seem not to have really progressed that much since the dawn of time ; Want a User Interface ? Code, comment, compile, link, test, check-in … same as its ever been. Eclipse and other IDE’s are great tools, no doubt, but they are still hard-core programmer tools, requiring complex setup and requiring deep understanding of the tool itself to make them really hum. Xcode meanwhile faces few of the issues that Eclipse does, but the creation of a UI for an app, and the tying of that UI to the code is no less complex.

Where are the tools that allow the really easy visual design of native User Interfaces with integration to visual design tools ? Why is it so complex to just get started – particularly with iOS developer certificates, provisioning profiles and the rest – and why is the process of pushing an app out to through the app stores a pain ?

My hypothesis is that the processes and tools are at the end of their very first iteration (or errortation as a colleague used to say), however I’m worried that a closed shop such as Apple will be slow to see or address the shortcomings of their toolset while they are reaping the rewards from the iTunes store. There might be a high technical hurdle to iOS coding, but it is still resulting in many thousands of apps being created on a daily basis.

I don’t have a specific view on what the next iteration of tools might bring, but frameworks with a generative nature like rails, and languages/environments like Scratch hint at a different way of doing things. Nothing particularly new about either of these, but I would like to see more smart tools that take away the drudgery and bring a new accessibility that means the number of apps will multiply exponentially from where it is now. Tools that will support the coming boom in DIY devices and 3D models from maker-land.

HTC Salsa apps limit

I have a new HTC Salsa. Black.

It really feels like the successor to the HTC Legend – similar size and handling, with a less pronounced kick up at the end of the body, which, when you are on a call, ever so slightly curves the mic towards your mouth.

The feel of the phone is great, and the addition of a prominent and featured Facebook button (the only hard button on the front of the device) seems like a useful idea.

In practice, I found that I don’t really use the Facebook button. It functions differently depending on the context … if you are looking at a photo and press the F button, it uploads the photo, if you are listening to music and you press F, it posts the track, artist name and album artwork. If the phone is idle, then a quick press of the F button lets you post to your wall. All of these seem great, but for some reason I am just never compelled to use it even though like a lot of people, I spend a lot of time on FB.

Some of the other integration with Facebook is more useful – such as notifying you with suggestions of contacts that are on your phone, and on Facebook – prompting you to link the two contacts together. This works really well, but I’m not sure this is new to the Salsa – I think this was the same on Legend and other HTC’s.

I have come across a fairly annoying limitation with the Salsa/Android. The phone only has 150Mb of internal memory, which is largely taken up – about 2/3 – by factory installed apps from HTC and Google. This only leaves about 50Mb for apps, which might sound like a lot (and would be plenty if any app could be copied off to the SD card), but in practice it fills up very very quickly. Install Google maps updates, Facebook, Foursquare, Angry Birds  and Shazam and you’re pretty much out of room.

This is such an annoying miss by the Android creators. Apple have made memory management a thing of the past, whereas for Android its left to the user to manually copy apps back and forth out of internal memory onto SD. A really poorly executed experience, which will limit apps takeup for owners of this phone.

Back to Nokia

For my upcoming holiday I’ve decided I need to have a phone with a decent camera, that is capable of taking HD video. Investigating this, it seems that there are many phones around that purport to do HD video, but there are few that are highly rated.

The phone-geeks here in the office say that there is still only one that stands head and shoulders above the rest, in terms of image quality, flash and lens … the Nokia N8.

Surprise !

So while Nokia have chosen to compromise the ID of the phone in favour of high quality images/video (the Carl Zeiss lens is so big that it forms an fairly unattractive bump on the outside of the phone which they’ve tried their best to disguised) – they obviously have their principles – and I’ll be taking an N8 to the US with me instead of an iPhone/HTC/Blackberry/ …

[UPDATE] Well, the N8 didn’t work out as expected. It was so complex to get around the camera functions that I decided not to take it on holiday. The image quality is good, but not so good that I’d swap out my iPhone. So, my holiday equipment was an iPhone for the snaps and opportunistic shots, and a Sony DSLR for the serious ones.

SXSW redux

It’s a month or more since I got back from my first visit to SXSW in Austin, Texas – and some of the takeaways from the conference are finally starting to properly take shape.

First, I have been coming round to realise how important it is to recruit and retain talented people. There was a lot of angst at SXSW from people either looking for a gig, or trying to employ good people. The common theme was that as soon as you find someone who’s good, they get snapped up by Facebook/Google and the rest.

Second, there are no new ideas. Not a new one in itself this, but just having a good idea in this world is nowhere near good enough – you really need to be able to execute well. There were a multitude of group messaging apps at SXSW but even though they were attracting a lot of attention (and investment) in truth there were several which were no good and will dissappear with out trace as quickly as they emerged.

Third, HTML5 is definitely the future, but is not the “right now”. No matter how annoying the fragmenting apps. ecosystems are, developers can’t drag themselves away from the real money available through the app. stores, and their clients want to have a presence in the app. store as well. The iTunes app. store that is – forget about the geek-fest that is still the Android marketplace.

Skunkworks

I’ve recently been having first-hand experience in integrating what started out as a skunkworks – a separate, autonomous business unit put together for a specific project – back into an existing business. After getting over wondering why my pet project was suddenly having such a hard time – it felt like the skunkworks was under attack – I realised that there must have been 1000 other similar projects, in 1000 other companies which have had the same experience.

The scenario is something like this :

  • Existing business processes are perceived to be bureaucratic, slow, unwieldy and conservative
  • A senior manager successfully lobbies to establish a special project/innovation team/skunkworks
  • The skunkworks is formed, upsetting everyone in the existing business because it brings up a mix of emotions … disempowerment, lack of recognition of the successes that existing processes can produce, the feeling of being sidelined or left out, anger, and everything else on the spectrum

If the skunkworks is successful, the problem becomes assessing whether its success is because of its autonomy and different approach, or whether the skunkworks approach just happened to be suitable for the project in question.

Sometimes the skunkworks is successful, but under cultural pressure starts to meld into the original business, taking on the attributes and more conservative approach of the original.

In some instances, it may be desirable to merge the skunkworks back into the original company. If the skunkworks has been in existence for some time, this may prove difficult as the culture of the two business units will by now be quite different, especially apparent if the skunkworks has been setup to be physically remote from the original business.

Any way you cut it, the setup of a skunkworks in the first place needs a lot of drive, and huge persistence to make it successful. Disbanding or merging it back into the original business can require just as much effort.

Apple uprising

Apple just released changes to their pricing structures, and are receiving a heavy backlash from larger publishers and from some smaller app creators who are crying “not fair”.

In essence this change restricts publishers from selling access to any portions of their app outside of the app store, and ensures that 30% of the sale price goes to Apple.

In the US there are rumblings of an anti-trust investigation, which I think I’m right in saying would be the first time that Apple have received this sort of attention.

I’m sure Apple are going to take this in their stride, and that publishers of all sizes will eventually just quieten down/roll over and accept the might of Apple, but there’s another long-term scenario that I imagine could be starting to play out here…

If you squeeze your eyes tightly closed, you could picture an Apple without Steve Jobs at all, and someone else at the helm who is not quite so controlling, and possibly still believes in Apple as the challenger brand, the benefactor, the champion of User Experience and friend of the niche markets. This new boss could start to be swayed by the weight of press and popular opinion and start to cave on some of these less popular issues. Maybe losing Jobs will have less impact on the inspiring products, but more impact on the business models that Apple chooses to put in place, resulting in a less powerful, more altruistic Apple over time.

Just maybe.

%d bloggers like this: