Do NOT Purchase the HTC Vive

Background

I purchased my HTC Vive less than 2 years ago from Amazon. I was initially impressed with it despite its limitations. The low resolution meant that it was far from perfect but compared to other devices on the market it had more capabilities such as room scale tracking and I felt that I had some hardware that I could enjoy for several years and looked forward to the software that would inevitably come.

It didn’t happen. Pretty much all the software is a glorified tech demo whilst competitors such as Facebook with the Oculus Rift and Sony with PSVR have been more considerate of their customers by forming partnerships and exclusive deals to produce software that is consumer focused and can engage you for more than a few minutes.

HTC instead, have decided to focus all their energy on corporate VR such as potential VR arcades, conferences etc and completely ignored the consumers who invested heavily in the Vive. This couldn’t be more evident than the reaction to their latest product – HTC Vice Pro. It is $800 just for the headset, will not be compatible with an upcoming wireless adapter without purchasing additional compatibility kits, and has been reported to be much heavier and less comfortable than the original Vive. Hence why no-one is buying it.

Faulty

To my frustration, one of the base stations recently developed a fault. This particular fault is called fault 03 and is extremely common. So common in fact that when I raised an RMA ticket with HTC about this they confirmed that…

“The repair process would take up to 2 weeks as we have been seeing a lot of delays on the repair processes, we are striving to see it happening much faster but I cannot promise a faster process”.

You can read more about fault 03 here:

• https://community.viveport.com/t5/Technical-Support/Fault-03-Error-10010-on-base-station-red-blinking-light/td-p/8004
• https://steamcommunity.com/app/250820/discussions/0/152390648083869888/
• https://www.reddit.com/r/Vive/comments/5uspjs/got_my_vive_today_base_station_fault_03_after/

After providing my serial numbers for both the headset and the base station (and chasing up after several days of being ignored) I was informed that a repair would only be possible if I paid $90. I will NOT be paying $90.

This means that HTC think it is acceptable for a key component in room scale tracking to fail within less than 2 years. This is a component that remains stationary and mounted to the corner of a play space. I can’t even comprehend how HTC would think anyone would agree to spending $90 for something that would cost $135 to replace with a completely new unit.

What makes all of this much worse is that HTC Vive’s are currently shipping with tweaked base stations that demonstrates the original design had issues that needed to be fixed but HTC are not doing the right thing for the customers that have the failed design prone to faults and instead expect them to pay the wholesale price of a replacement for it to be ‘repaired’. See: https://www.roadtovr.com/latest-vive-shipping-with-tweaked-base-stations-redesigned-packaging/

In summary, HTC Vive hardware is not expected to last more than a year, hence the warranty and lack of any support from HTC once that year has expired.

What Next

I will not be replacing or repairing my base station. HTC have made their position clear. They are not creating products for consumers and do not care about their customers. Instead I will be selling the remainder of my HTC Vive hardware.

The HTC Vive is already not able to compete on price with its competitors and doesn’t have any differentiating features anymore. The software available remains inferior to other VR systems and, as such, I will re-invest my money in one or more competing products such as the Oculus Rift from Facebook.

Please take this as a warning that HTC will not provide any after-sales support and do not value your custom.

AngularJS for a multi-page website? You’re Doing It Wrong!

There are some exceptions to the sweeping statement I am about to make but I am growing tired of seeing the same mistake being made when choosing a technology stack for a multi-page web application implementation…

So… What’s Wrong With AngularJS?

AngularJS is a fantastic JavaScript framework and an excellent technology choice when building a web application with a single page architecture. There is nothing inherently wrong with it that should exclude it from consideration if you are building a dashboard style application that you want to be interactive and are looking to mimic a native application user experience.

Can I use it for a website implementation?

You can, but before you do you should ask yourself some questions:

1. Does your implementation have more than one page?
2. Does progressive enhancement give you everything that a SPA would offer?
3. Do I care about SEO?

If you answer ‘yes’ to any of the above questions, you should seriously consider an alternative approach.

My web application DOES have more than 1 page

If you are building a web application to serve requests for different pages of content then a single page architecture is counter intuitive and akin to forcing a square peg into a round hole.

You are going to invest time and resources into producing a web application that might look fantastic but falls over completely without JavaScript enabled.

Neither hash bangs (#!) or HTML’s history API have provided a solution to the problems when trying to implement a multi-page web application using a single page architecture JavaScript framework.

How can progressive enhancement help?

Despite all the advances in crawler technology, a server-side technology is still far superior at serving multi-page content. Server-side technologies are far more mature than the emerging JavaScript frameworks and the total cost of ownership for equivalent solutions are much lower.

The primary reason I hear for wanting to use AngularJS or any of the other SPA JavaScript frameworks is to have a native app feel by removing the visible loading of a page when browsing pages on the web application.

This can very easily be achieved without the bloat that comes with a framework such as AngularJS. You can use JavaScript to override the default behavior of a hyperlink so that you request the page via ajax, parse the content from an inner DOM container, and drop it onto the current page.

Alternatively, you can expose CaaS so that the initial page load is rendered server-side with subsequent updates being fetched via Ajax. This is different to an SPA implementation in that the content is still rendered on the server-side before being injected into the page by JavaScript.

What about SEO?

If you serve a single page architecture that takes over the routing of your website you give your visitors a different browsing experience than the search engine crawlers that will visit you.

The usual proposed solution to this is to detect crawlers and serve a different page that can be effectively crawled so now you have two implementations to maintain instead of just the one.

You can use the HTML5 history API and push state to modify the url as you navigate SPA implementation but unless this url is stateless and would present the same page and state as you currently have it isn’t a consistent experience. The same consideration applies when considering social sharing. A url should be stateless so that when you share a url it reflects the content you initially shared rather than contextual content based on the journey you took to arrive at that url.

The far better approach is to have a multi-page web application that can serve the appropriate content by url using hyperlinks and other HTML standard features. Then, using custom JavaScript or a lightweight JavaScript framework, introduce progressive enhancement for those visitors that have it enabled.

This will give you a consistent experience for crawlers and visitors whilst only maintaining a single implementation. You’ll also be able to achieve exactly the same user experience that a SPA JavaScript framework can provide but at a far lower total cost of ownership.

So SPA is great, but not for multi-page websites

Another benefit is that, with the business logic and rendering primarily on the server-side you do not need to come up with the solution to problems that have already been solved beforehand in areas such as security, state, social etc.

It’s a shame to use the wrong technology stack just because you failed to ask the right questions before investing time and resources into a new web application implementation. Especially if the only reason for using the wrong technology was because it is new and trendy or because the CEO heard good things about it.

The 1 Killer Feature Missing from SDL Web 8 (formerly Tridion)

For several years I have worked on a number of different SDL Web 8 and Tridion implementations and on almost every single one I have wanted an elusive feature that is not available out of the box.

When you are preparing a website for content management, you invariably have to make a compromise between having style fields in the content schema metadata or in the component template metadata. There is a trade-off in either case because, if you put style fields in the content schema you’ll have to duplicate content for the purpose of styling – that’s BAD! However, the alternative results in potentially having LOTS of component templates for all the style variations. If you have fields for the block size, color, borders etc you can soon run into problems.

The solution to this would be to have the schema only model content and it’s metadata as intended. To have the component template metadata include instructions that dictate how it should be rendered. And to have style or theme fields on component presentation metadata – a structure that doesn’t exist until you combine a component with a suitable component template.

There is even a sensible place to curate these fields in the UI…

Edit Page UI in SDL Tridion 2013

The component presentation metadata would feature as a contextual tab alongside the Component Presentation and Target Groups tabs and would be specific to the highlighted component presentation and stored with the component presentation in the CM data store.

Similar to how a component template can define it’s parameters schema or metadata schema, it should be able to define it’s component presentation metadata schema also so that the correct fields are presented accordingly. You might want different component presentation metadata for different component templates right?

This would require some architectural additions to the product but imagine being able to use an IComponentPresentation in DD4T or DXA to access the component presentation metadata with information about how to theme this particular template? The component template remains responsible for how it should be rendered but there is more information obtained when the content editor selected this component template to inform us how they want to use it for this particular occurrence.

This doesn’t break the way any of the concepts are currently applied or implemented but extends them with a new feature that would vastly improve the re-usability of components and/or component templates without limiting the flexibility in the rendering phase of content delivery.

We are often able to customize and extend the product with a wealth of excellent extension points from GUI extensions and CoreService APIs etc. However, because this would require some extension of the CM data store, it would be better suited as an extension to the core product opposed to a community developed extension.