This article is a bit of a rant, but I’m going to try and keep it reasonably light.
To me it feels like the web is playing catch-up and no I’m not talking about catching up with mobile apps either – behave.
“Software, Be Different Everywhere”
By software, I am referring to anything written with a program language. Just think of desktop software, web sites, mobiles and anything else you can cook up, which comes with a UI.
We’ve had this false belief that web sites should look identical everywhere. “Hardboiled Web Design” is dedicated to addressing this myth and Andy Clark discusses some of his techniques for using HTML5 and CSS3 by progressively enhancing the site using Modernizr (I’d rather see it use all the bells and whistles and gradually degrade).
In the mobile world we’ve seen the same belief, all mobile apps should look the same. iOS apps being ported directly to Android, splash screen an all.
I don’t think desktop software has gone through the same trend, generally they have always had separate clients, but any cross platform applications that do exist, should they have to be the same as a requirement?
“You, Be Awesome to Yourself”
Don’t tell yourself everything has to be the same.
Different browsers support different specs. Different versions of browsers can be distances apart in capabilities. Don’t dumb everything down across the board and then fight on top of that to fix weird quirks. Do fantastic stuff and then degrade for the older stuff in a way that makes it work and minimizes the pain for you.
Mobile applications have different user interactions patterns. If you try to fight them, to match another platforms flow and design, and you are going to have problems. Design for each platform and feel warm and gooey inside as you are safe in the knowledge that you won’t be digging a hole for yourself when you can’t quite make it match up.
“Tooling, Be Easy and Kind”
When you start looking into web development, it’s an utter confusion-fest.
Bootstraps
Grids
CSS3 vendor prefixes, browser support
HTML5 browser support
Boilerplate
Javascript libraries & frameworks
IDE’s
Responsive Design
….. and this is only the stuff I’ve looked into
As a new comer to web development, how the hell do I get skilled up enough to make the right decision on tools like this?
At the moment I’m intending on doing a short screencast just to go over how I’ve started developing a redesign of this site and cover off some of the tools I’ve found invaluable.
The thing is, no one seems to write content about this from a start to finish attitude. It’s a case of, “this new tool is awesome for X reason”. Well that’s great, but I don’t know what X does let alone how it fits into the grand scheme of my site. I can appreciate that it’s moving fast, but too fast to document in blog posts….
“Design, Be Pretty Everywhere”
This is the final point.
Why is it that a responsive design seems to be nothing more than a desktop site, with everything, sort of squished down?
Let’s be honest, if we downloaded a native application on our phone and it had the same UI as a standard responsive web site, the majority of people would sit there and scream | cry | weep for humanity | sacrifice a small child to make the pain stop.
I’m not saying – go forth and write web apps for these types of devices, but bare it in mind and since we’re on the topic of screen size, think about the other end of the spectrum with TV’s and projectors, not a desktop with a mouse, but a screen with a D-Pad (or other input device).
Web sites should be flexible, they should look great everywhere, but not the same, not just squished down, but look and act the way you would if you were asked to make it work for this one device type.
“Conclusion, Be Brief”
Web is advancing fast in terms of features with HTML5 & CSS3, but hunt for a solution you have to a problem on sites like stackoverflow and you’ll see a range of answers supporting old browsers using old techniques. (Whilst searching for how to make a site horizontally scroll I was shown table solutions and float solutions. Where was the flex box option with nowrap?)
The tools that make it easy and quick to develop for the web are catching up, but it’s disjointed and hard to enter the web development world from a fresh set of eyes and make a decision.
The world outside of the web is changing fast and the web is failing to keep up, although I’m expecting that to change over time and as it does there will be a shift to web as a main focus for development across devices.
A couple of people have had issues with the aspect ratio of their videos not being what they expected on Google TV.
The problem seems to come from the VideoView sizing itself in the layout and making the SurfaceHolder the same size, regardless of video content.
By fixing the size of the SurfaceHolder you have a good canvas for the video to be drawn on, then ensure the size of the VideoView is the right aspect ratio so as it sizes the SurfaceHolder, it’s uniform with the video size.
I started digging into the issue and came up with a simple library, which allows you to insert the width and height of the video source, which the VideoView will then stick to by sizing the SurfaceHolder and then overriding the onMeasure method. Simple.
How do I use it I hear you cry. Well, start by grabbing the library project from the link below and add it to your project:
Instead of using a VideoView in your layouts, use the following:
Then in your source code do something along the lines of:
That should be all you need to do. This has only been tested across a couple of media sources, but if you use it and find issues then please create a bug here and we’ll see what we can do: https://code.google.com/p/googletv-android-samples/issues/list
This is largely for self reference, but is useful if you are just starting to look at CodeIgniter.
Firstly, everything has an index.php in front of the URL parameters. For example, I might want to have www.gauntface.co.uk/apps/ which would show all the apps I’ve worked on. Unfortunately this needs to be www.gauntface.co.uk/index.php. To remove that annoying blighter, we start our journey at the codeigniter docs http://ellislab.com/codeigniter/user-guide/general/urls.html.
The .htaccess file holds all the power (of course it does). However things to note.
If you want images, css, js etc to be ignored by this rewrite rule, trust me you will, then ensure you add the correct path to the second line. Mine currently looks like RewriteCond $1 !^(index\.php|images|css|js|robots\.txt)
You need to have the Rewrite module enabled. This can be easily achieved via the commands ‘sudo a2enmod rewrite’ && ‘sudo /etc/init.d/apache2 restart’
Here’s a nifty trick Les Vogel introduced me to, to set a global git ignore file.
Then for me I add in the following:
The only down side I can see to this is if you are working on a team, this is no longer synced up with a projects repo (i.e. having a .gitignore file in the project directory), which isn’t a problem if you know everyone you are working with, but for open source projects it relies on others sticking to a similar approach and I wonder if it’s easier in the long run to have a local .gitignore file and avoid unwanted files being committed from contributors who don’t have the same set up.
I was lucky enough to travel around presenting an Intro to Google TV at a number of events and here are the slides from Droidcon NL, the last event of 2012
Anyone developing an application for any platform should consider their UI from the outset, which relies heavily on understanding how people will interact with their app.
At the moment there is a lot of debate within the Android community regarding how to implement the Drawer design pattern in Android.
Generally, developers love the concept and see where it fits in with the platform, it’s the details that are still needing to be ironed out. Personally I love the design pattern, it’s an easy way of including functionality without bombarding users with tonnes of options.
Regardless of the details of how it’s implemented, the question is, does this suite Google TV?
In short: yes
If you have a need for offering a wide range of functionality to a user, then the Drawer design pattern is probably right for you, so the real question is how should implement it?
The best library I’ve seen to achieve this kind of interaction is the SlidingMenu available on GitHub. Not only is the library fairly active in terms of development, but it’s easy to use and handles focusing really well.
I made a simple test environment to see how some of the popular sliding menu’s worked when placed in an application with fragments side by side and how they re-act when navigating with the focus.
Given the focus position above you can start to interact with the Drawer by focusing left which will open the drawer.
From here a user can hit left to interact with the Drawer contents or hit right and the drawer will close. At the moment there are a number of ways beyond this to toggle the drawer open and shut:
Focus left and right to open / close the drawer. The key question here is should the user be required to hit the direction once to open the drawer and then hit a second time to actually focus on the drawer’s views, or should the drawer open and gain focus straight away?
Personally I feel that this is a nice way of interacting with the focus. By changing the UI in such an extensive way, that if you moved the focus with the UI change, it could become confusing to the user as to where they are within the interface.
It’s become standard practice for an Android applications to have the ActionBar home icon toggle the Drawer which is easy to add in.
Something specific to Google TV – Use the menu button on the remote control to toggle the drawer. At the moment there are a number of applications which will use the standard Options Menu API which will display a Dialog with the relevant actions. This design pattern could replace this, especially since the menu button is deprecated in newer android devices.
The things to consider here are: this drawer should only be available at the root of the application, if the menu button is used to open / close the drawer, will it confuse users when the drawer isn’t available?
Should the focus be moved to the drawer when the menu button is pressed? I am on the fence for this one, if the user presses the menu button then gaining focus does make sense, but if the menu button is pressed by accident it could really disorientate / frustrate users.
If you use a sliding menu in your application let us know what you & your users think of it. We are seeing more and more applications using the drawers and it is helping the community come to a consensus as to what is the best way to implement it, these are some additional area’s to consider when targeting Google TV.
You’ve made your website for Google TV, it’s looking damn fine, but you’ve hard coded a width, eek, how do I handle 720p & 1080p . . . . I know I’ll zoom the hell out of it.
This is a fairly common use case, generally I would strongly encourage developers to create websites which are responsive and handle different screen sizes accordingly, but the history of web development has shown that fixed width pages are fairly common, especially moving from designs to HTML + CSS.
The recommendation from the Google TV team has been to apply a CSS zoom property to enlarge your UI, however some developers found minor artefacts and sprite issues would appear as a result.
One alternative to this approach is to use -webkit-transform: scale(1.x) which scales the UI and seems to do a better job at avoiding artefacts.
