I dont know enough about smart watches but i figure that at some point, browsing web sites on them will become a standard feature. The "Web Browser for Android Wear" app on google play has more than 100,000 downloads and the "WebBrowser for SmartWatch" app has more than 10,000
To that end, given that smart watches like Sony's SmartWatch 3 has a 1.6” screen, what should web designers need to take into consideration when making their web pages as portable as possible? Is there a set of standards? What kind of functionality and behaviour should one expect of a page displayed in a smart watch browser?
Although SO isn't the best place for this question, I'll chip in. As far as I know, designing for wearables is still a new thing, and as per say, I haven't come across any standards as such.
But I think responsive web design should do just fine.
People are working on designing websites for smart watches. Here.
However, think about using the standard manufacturer APIs to build more robust and interactive experiences than just relying on websites on tiny screens.
Here's an article from Net Tuts+ that shows you how to design for the Apple Watch using existing web technologies. Bear in mind it doesn't beat native at all.
Related
I am considering using a web application in place of a traditional UI to control an imaging system. The UI will allow the user to do things like change settings, upload scripts, start/stop data acquisition, view data, etc... Rather than a monolithic UI that "does everything", an embedded controller would interact with system hardware and control the process, receiving commands from the UI over a local network.
I would probably use a javascript toolkit or perhaps some .Net technology to build the web application. A few of the advantages I see are:
Access UI from any browser.
No software to install.
Access remotely if necessary.
View status/data from multiple computers simultaneously.
Modular (separation of concerns)
Data as a web service.
A few of my concerns would be:
Lack of a comprehensive widget toolkit.
Supporting multiple browsers, this may not be as bad as I think now with HTML5.
Updating the UI from the server.
My questions are, Is this common? Is it a bad idea?
If it's really subjective, I understand, however, I just wanted to see if there is an obvious answer, like "DON'T DO IT!!!!"
It is very common. I do it all the time, particularly for a closed community of users such as you will have.
It might be different if this was a public facing device, but it is not.
You are going to support more devices by saying "you must have an HTML 5 browser" than if you said "You must have a PC" or "You must have a Mac"
In terms of your concerns, I do not see any of them as being an issue.
It is easier to deploy a UI upgrade once to the imaging controller than many times to all of the client machines.
There are all of the widgets that you could ever want available for HTML 5 compatible browsers
You answered your own question about cross browser issues. HTML 5 browsers are free so there is no downside for people to upgrade to them and you have the entire weight of the world wide web pushing them to upgrade to take advantage of what can be done with HTML 5 so users have a big incentive to upgrade. I do not run into any push back when I require a closed group to use an HTML 5 compatible browser. And if you want to be kind to those that don't have html 5, you can always use modernizr.
It is a good idea - and there is plenty of examples and ways of doing what you want to do.
I have made one windows phone based application. i want some designing ideas from you wp7 people.how can we apply styles,transparent background or the design which suits wp7 app. may i have some links which provides snaps for good designed apps. please help
One app that jumps to my mind when talking about great use and adaption to the metro design, it's "Cocktail Flow". It has very well done implementations of many design cues for WP7. As special treats it has features like parallax effects controled via gyroscope.
You can find a free version on the marketplace. Definitely worth a look.
MSDN user experience guidelines are pretty good, User Experience Design Guidelines for Windows Phone.
Also, it helps to install some popular apps from the marketplace and study their design.
The BEST thing you can possibly do to get a good idea of how to build a great WP7 app is to own a Windows Phone, and use it as your primary phone.
Get used to the way the operating system flows. Download cool apps. As time goes on you begin to understand from the user's perspective what a "good" app looks (and more importantly) feels like. It's a hard thing to nail down in a "user experience" spec. I find that a lot of people who set off to build a WP7 app do so before understanding how apps are supposed to behave on the platform. It is vital that you understand how users expect applications on the windows phone to operate. If you use a windows phone for a good 3-4 months, and really make an effort of butting it through the steps, it will be hard to walk away from that experience without a very clear idea of what a "good" application looks like for the windows phone.
That being said, and while I honestly don't believe that there are any short cuts to good design for the windows phone, I highly recommend downloading the following apps, and playing around with them to get a feel for "good" UI:
Wordament
Cocktail Flow (previously mentioned)
Twitter
Spotify
Yelp
Any of the built in applications (Office, Zune, Internet Explorer)
The above are good to start with, but again, you're really not going to understand it unless you live and breath it everyday for at least a few months.
We're working on the next version of a tracking system. The previous incarnation used an LCD with a simple custom UI however as we've had usability problems and we've found development time-consuming, and as our display is going out of production, we're considering using a regular cellphone or PDA as the interface instead.
Our main worry is whether we can keep such a product on the market for five to ten years without having to continually keep porting and adapting the application to new devices. To make things somewhat easier we intend to bundle the phones with the system, though in an ideal world our (largely non-technical) users would be able to use their own.
So, what's our best bet? Are there a good platform-independent libraries we can count on being supported for a while? Or are we better of betting on a single platform at a time? Perhaps backward-compatibility is more likely to be maintained on a PDA? Truth be told I'm not even sure what language to bet on for the generic parts of the code.
I'm also a little anxious about the link to our hardware. Bluetooth SPP is attractive since it's particularly easy to use and there are plenty of ready-made modules available, but support on the phone side is far from universal.
Any pragmatic advice would be most welcome as I must admit to having no experience with mobile application development.
If you don't control the entire production chain for hardware like Apple does for example, you have no chance on long term. Unless your product is really innovative and market wants it so much, or if you are playing on a market niche (healthcare for instance). My proposal would be to make a market study and check what your customer use as mobile devices first. You should choose one or two top platforms first, and gradually add new platforms if market asks. If you are in US probably iPhone, Android, RIM would be the top choices, in Europe I would have to choose between iPhone, Android, Symbian, Windows. It's the same like developing a website you start with two top browsers and gradually add support for minor ones.
About portable libraries I wouldn't bet on this. Instead I would design an architecture using abstraction layers. For example I would have Bluetooth abstraction layer that would expose functionalities to my Business Logic Layer; underneath I would have BlueZ if I deploy on Android/Linux, maybe GameKit for iPhone, MS stack or Widcomm for Windows and so on.
PDAs are dead, actually they've merged into smartphones and tablets, they were an evolutionary step. So forget them.
HTML5 is a good idea but is only the front layer, you must deal also business logic and lower layers.
Bluetooth SPP is good because it is common, and interoperable it's like the webservices for enterprise. Instead of giving an API that is platform dependent you could provide a set of custom AT commands, that can be used by anyone that can connect on Bluetooth to SPP.
Cross platform sounds like HTML 5, CSS and Javascript, along with some javascript frameworks for mobile development like the ones listed here
Is it true that web browsers as we know today have no future? That programmers should write native clients for their application on many devices?
I'm writing web application with AJAX but should I also prepare versions to many mobile devices?
The web will be around and web browsers are available on almost any device. Some say native development is the future, because it is closer to the device and gets the most out of the system. This is true and is applied in various cases, like XBOX games and Apple software that is especially designed for a single device.
Other developments show the other side. Google's OS is barely more than a webbrowser. All applications running on it are merely web applications that should run on any browser. Only difference is that the engine of Chrome OS is put directly onto the hardware, allowing the webpage to get a better performance, because it has only one abstraction layer to the hardware instead of 3 or 4.
So, the only advice I can give is not to worry about it. People on either side have been declaring the other technique to be dead since decades ago, but both are still here. When it is time to switch, you will know. :)
The first statement is definitely not true.
The second one depends on your case, but most things you can just do "mobile-browser friendly". I.e. make a mobile version of the website that looks good on mobile browsers. No need for mobile applications.
Of course, if you have the resources, a mobile app is a good addition to your portfolio / brand.
First of all no one knows and no one can know what the future will bring.
For me though, it is difficult to imagine a world without web browsers at least in the near/mid term future, especially with all the hype/support behind HTML 5.
The big advantage is of HTML 5 in this regard is write once, run everywhere.
My 2 cents ;-)
If anything, it is the other way around. Make a good web application, and everyone can use it. Mobile browsers get better and better all the time. Expect mobile website usage to increase, rather than custom applications for each device. (obviously, applications that need hardware access are not included in this statement.)
Furthermore, expect a convergence between mobile web and desktop web.
I am about to start developing a desktop application, and I am interested in making the application both usable and accessible for end users. Can anyone suggest online resources that offer guidance for developing usable desktop applications? In particular, I would be interested in learning about how to test desktop applications for usability. I am aware of several tools to validate HTML for accessibility; how could you test a desktop application for accessibility?
Thanks, MagicAndi.
I read through the entire Introduction to Apple Human Interface Guidelines, and it was not to my loss. Rumor has it that similar guidelines for MS Windows and Gnome are excellent, too, but I haven't read those.
Wikipedia has interesting pointers to usability. The single best (short) piece of literature I've seen on usability is "Don't make me think" by Steven Krug, with a focus on Web Usability.
As for Accessibility, I haven't read through all of it, but from small exerpts I blieve that real experts have written WIA-ARIA, the W3C take on accessibility.
I forgot where, but these are hints I've learned on how to test for accessibility:
Buy a screenreader and try to use your app with that
Put on glasses that are not yours (or take yours off) and find your way through the app
Try to handle the your App with an imprecise substitute for a mouse, to simulate disabilities of the hand. E.g., try using your app with a trackball, or with a mouse on a reflecting surface.
Turn the sound very silent or off
Use your app with one hand only.
Set your screen to black and white (to check that contrast suffices)
That's all I can come up with now.
I can answer from a MS centric point of view, although some of the tools mentioned should work for other languages that run under Windows.
First there are two open source options on CodePlex that you can run against your applications to verify that you have the building blocks in place for accessibility AccChecker and UI Automation Verify.
You should also use a screen reader to verify your accessibility, in my experience a good one that works with Windows and WPF applications is NVDA Screen Reader.
For measuring luminosity ratios of UI elements I like Colour Contrast Analyzer v 2.2
Microsoft also provides guidance with their Accessibility Labs and Sarah Ford has a really good article providing a great overview of accessibility testing http://msdn.microsoft.com/en-us/library/ms971307.aspx