My boss has asked me to create the technical requirements for a design consultancy who are going to be tasked with creating a demo of our website.
To be honest I don't any more about Flash than your typical Youtube user, so I'm floundering a bit!
The website to be demo'd is is designed to run at a minimum res of 1024x768. We'd like to be able to show it on any device, but I suspect text would be unreadable on any mobile devices, so they're probably out of the equation...(?)
So far, I've got these requirements, but I suspect some of them are redundant, or too open to make any odds... do you have any suggestions?
FLV file
Player version:
Adobe Flash Player v6+
Adobe Flash Lite v3+
Browser compliance:
IE6,7,8
Firefox 3,4
Chrome, Safari, Opera latest versions
OS compliance:
Windows 2000, XP, Vista, Win7
Mac OS X
Linux (?)
Mobile:
?
Web compliance:
(our wesbite is
!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd")
Security
Flash cookies: no
Any help would be much appreciated!
Flash V6 is really a tough requirement. It's 8 years old!
IE6 is also quite hard to meet without (useless) additional development costs.
If you want to exclude mobile devices, you should also exclude FlashLite and ask for a more recent version of Flash.
In general, if you have no reason for sticking to one version, don't stick to it.
Flash 10, IE7, FF3, Chrome, Safari, Opera.
OS requirement is useless since it doesn't change anything to the browsing interpretation and experience.
Web compliance is a matter you want to consider for Search Engine Optimization, accessibility, compatibility...
For the flash version, you're safe targetting FP10, and you could even bump for 10.1: http://www.adobe.com/products/player_census/flashplayer/version_penetration.html
I'd specify AS3, as any design company still using AS2 for their flash needs as so far behind the curve that I wouldn't have confidence in their abilities.
Ignore browser compliance: it's flash, it just works.
Ignore OS compliance: it's flash, it just works (At the very least they should test it though).
Mobile: For the most part, if the phone supports flash, you should be fine. Where this is important though is optimisation (small file size for SWF and assets, good memory management, good speed, throttling the frame rate when it's not needed...). Depending on your site and what you do, take care with video etc. Basically, anything you see on Flash Site of the Day (http://www.thefwa.com/) is probably going to brick your phone, so it's really how important this is to you.
Web compliance: if you want your site to be indexable by Google etc, it takes extra work
Accessibility: if you want your site to be usable by special needs users (screen readers, keyboard-only navigation etc), it takes extra work.
Security flash cookies: not sure what you mean by this, but cookies are standard and probably done at a browser level rather than flash level (unless you're using shared objects for storing settings etc). In any case, it's not really a problem
Depending on how much flash is in the site (i.e. if it's a full flash site, or a html site with flash elements) these points become stronger or weaker - if you're including html in the bargain then you've different elements to look for. For the most part, the company should know all this stuff if they're any good.
Depending on how much content you have in your site, it may need an internal search (takes more work), or work with internal pages (i.e. it's possible to go to mysite.com/shop/item#blah and not be only able to go to mysite.com and have to manually navigate to the page every time)
A final point I'd put in is to make sure it's actually useful. Full flash sites that are just flashgasm intros and 20 minute long transitions betweens pages etc really suck. Hard. It might look cool but you'll hurt your business as for most people your site is useful if it's convenient.
Related
We are going to redevelop one website we developed as an ASP.NET website to be a mobile one.
So, I'm wondering how does the development of a mobile website differ from a normal one?
Also, what is the best approach to do this taken in consideration that this mobile website will be browsed mainly from iPhone?
There are a number of differences between a mobile device and a standard computer.
The screens are much smaller (fewer pixels to display your page). You should put fewer elements on each page.
They are typically viewed in portrait mode (narrow display - narrow page). You should plan on using the full width of the screen instead of setting a fixed page width like most people do on standard web pages.
People use finger gestures to manipulate the page instead of a mouse (buttons/links should be larger)
They can include additional features such as geo-location, telephone, etc. that you can incorporate into your app to be easier to use. There are some libraries available to help you use these, such as jQuery Mobile.
Users are concerned about battery life plus the CPU tends to be slower. Make sure you keep animations and client side processing to a minimum.
Users are concerned about data usage. Keep ajax calls to a minimum (don't ask the server for data every few seconds!) and use graphics sparingly (it's better to use html/CSS to make the page attractive).
Flash isn't supported on iPhone and is not well supported on other devices. However, most mobile devices have decent support for HTML5, so you can typically use that instead.
Users on smartphones are used a different experience.
In addition to Brian's answer I'd add:
Screens are not resized but scrolled, however sides scrolling is not generally a good experience
Screens orientations can change, but the same scrolling rules apply
Consumers are used App like behaviour and as such less information with backwards and forwards between pages is common and between sites
Consumers generally have data concerns so data traffic needs to be minimised
Controls/buttons/selections/data entry need to optimised for hand gestures - for example think of what happens with the keyboard pops up to allow data entry, how much screen is available - can the see all their input easily if they need to?
I suggest that for developing a mobile website is to use the target smartphone for a few weeks to understand how the device is used in the real world.
I'm afraid you cannot use current asp-View to mobile especially for iPhone. There's special control set for iphone development - componentone.
If you web application is based on MVC or MVP patterns then moving will be not difficult.
Recently we have developed a site for iphone users, we are using asp.net/sql for normal site.
But when you look at mobile sites, mobile normally have small screens and some time optimization problem.
We use jqtouch for mobile development. A JQuery plugin for mobile web development on the iPhone,Android, iPod Touch, and other forward-thinking devices.
Learning Video
Getting started
Establish the context for the mobile site: is there subset of information that is more relevant to your mobile users? Maybe your regular site has apps that are irrelevant on mobile devices? Either way, you should create your mobile site separately in a mobile folder! You can then use a sub-domain to reach it: for example, http://m.mysite.com
You can use a combination of CSS Media Queries and 51degrees.Mobi to detect browser features and render the correct size layout depending on which type of device the user has.
http://html5boilerplate.com/
http://www.modernizr.com/ (this is included in HTM5 Boilerplate)
http://51degrees.codeplex.com/
Do not make the stupid mistake of following current fads like "Responsive Web Design" which attempts to squeeze a desktop version of a website into a mobile screen. Above links should get you started.
My web site has a different mobile version that's suited for iPhone/Android devices. The problem, however, seems to be in the site's performance. It's really slow and heavy, even though I'm not loading any images.
On the other hand, when I use Gmail's or YouTube's mobile version, they're so fast they almost perform like a native mobile application.
How do they do that?
Your help is much appreciated :)
See my comment. Also, if the slowness you perceive is when interacting with the site it could be that it lacks the ability to accept touch events. On mobile web, if you have not wired up the UI for js touch events the experience will seem slower because the device browser has to fall back to standard click and other mouseevents which are not optimal. Frameworks such as mootools and jquerymobile/jqtouch have these events baked in. Take a look at the mootools solution which has quite a good write up: http://davidwalsh.name/mootools-touch
They probably making use of local storage http://dev.w3.org/html5/webstorage/
Are your pages too large? Try to use gzip and/or reduce output
Your server's connection speed may also be responsible of slowness
Well, You don't need to include any javascript framework to make it fast clickable.
By implementing some JavaScript you can achieve that. Google has released a solution for that
https://developers.google.com/mobile/articles/fast_buttons
This will allow visitor to interact with application native way. From Android 4 (as far as I remember) version by setting viewport meta tag the browser will automatically apply the fast click functionality.
For the animation issue always use Hardware accelerated animation with a fall back for older mobile browser. Using hardware accelerated animation it will make your application smooth as silk.
Follow this guideline and you can make your application as fast as gmail / youtube mobile version.
http://www.html5rocks.com/en/tutorials/speed/html5/
Best of luck.
Your webapp is consuming too much RAM. Don't use so many libraries and don't attach so many event handlers.
My wish is to know how I can program a mobile website, that fit to all mobile phones.
Are there any special approaches to recognize a device and render the code according to it?
Which tools and coding languages are required?
My first thought was to hold the website in XML, which would be parsed depending on the device.
You have to consider old phones, even devices with only wap support.
For example: The mobile website has to recognize Nokia N75 and render/send the code that looks optimal for this device. Same thing with an iPhone or a Motorola Razr.
There are all sorts of problems associated with developing mobile websites. Doing it well takes a lot of time and effort, as phones have such varying support of web standards. There are tools that do it for you, such as the Mobile Web Toolkit and Vodafone's PartnerMl. These tend to force you to write your pages using dedicated XML tags which describe a limited set of elements and styles that can be rendered on the page. The phone requests these xml pages, and the server side software intercepts the request, examines the type of phone (the User Agent), and serves back markup appropriate to that phone. The disadvantage of this system is that it is very inflexible; you are limited to the set of XML elements that the tool supplies, rather than the full flexibility of HTML.
If you want to do it yourself, essentially, you have to do the following.
Using server-side code, examine the User Agent in the Http Header. This tells you what kind of phone/browser made the request
Output appropriate markup and CSS for that user agent.
Useful tools are the User Agent Switcher add-in for Firefox. Using this, you can, for instance, visit the BBC's website, pretending to be various devices. You will see that the BBC outputs 3 or 4 versions of its markup, as well as 3 or 4 different versions of the CSS, depending on the user agent.
mobiForge contains useful information. WURFL and DeviceAtlas are databases that allow you to determine the capabilities of the device that has made the request.
You will quickly realise that you will have to keep your design simple, and it's best not to rely on Javascript, as only the most modern phones can handle it well.
XML is the way to go.
From there, you mosey on to parsing out and acting upon the Agent tags in the request.
From there you can choose (assuming the device supports it), having the device render it via XSLT, or you can apply the XSLT on your end and stream down the appropriate markup language for the device.
In the end, you end up with a specific "rendering" per device. Ideally, the more compatible the devices are with normal browsers, the close the final XSLT is to each other. But you'll still likely have a version for each device that you support.
The beauty of this is that you can add devices incrementally, as time and demand permits. And as devices converge, you gain value by being able to converge your renderings. Also, your back end stays the same no matter what.
Finally, it also works great for non-mobile as well.
Yea, it's a burden to support the different devices, but that's just a truth of the marketplace.
One way is to use strict html with very clear semantics and minimum of css tricking. Do only use relative measures (for example em and %). Trust the browsers default values, because they are in one way optimal for every device, more or less.
Nowadays there isn't exist good tools to do this.
A good practice is to respect the different W3C standards about the accessibility (like the WCAG, the XHTML, etc).
If you made your web site the most accessible as possible it'll be more adaptable. (independently from device, screen size, with or without screen touch...)
If you want more information you can read one of my article about the web accessibility here if you want: Guideline to move a website on a mobile device.
However you can use some meta tags to allow the web browser of the phone to adjust the content like this for the iPhone:
<meta name="viewport" content="width=device-width">
You might wanna check out WURFL
I've been asked to find out a sensible way to make the majority of popular websites detect our browser - which is functionally complete, but is running on rather constrained hardware - as a "mobile" browser. The idea is that the heaviest popular websites seem to have mobile versions, which render much faster and fit better on the screen.
I've looked at the inverse question, which tells me that there isn't an obvious standard way of doing it - http://www.brainhandles.com/techno-thoughts/detecting-mobile-browsers is a case in point. This is borne out by looking at a variety of User-Agent strings from popular mobile and desktop browsers.
So far the best idea we can come up with is to add "Mobile" to the string somewhere, since this is the main visible difference between Safari for iPad/iPhone and for Windows/Mac. Does anyone have a better idea?
If uniquely identifying yourself is unimportant you could simply copy the important parts of the User Agent string for a popular mobile device... one which would be an obvious omission from any mobile detection script.
So far the best idea we can come up with is to add "Mobile" to the string somewhere, since this is the main visible difference between Safari for iPad/iPhone and for Windows/Mac. Does anyone have a better idea?
This won't work. The vast majority of mobile phones don't include "Mobile" in their user agents. Here's a fairly huge list of mobile user agents. As you can see, there's no consistency. On top of that, new user agents are being added to the market on a weekly basis.
I want to allow our main application to generate document files that can be easily read on the iphone, or other smart phones. The easiest way to do this, I think, is to create a simple HTML file and use javascript to show / hide different bits of it. For example, when the user clicks / touches "section 1", the section expands to show its full details; otherwise, it will remain collapsed to save space.
What guidelines should I follow when creating this file? I've done a little research and arrived at the following:
The iphone has a native resolution of 320x480, but only about 320x400 is visible for a web page.
Other smartphones have resolutions from 160x120 (probably not high enough to bother with) up to 320x240 and some even have 480x640.
These are useful for deciding how to style and arrange the HTML output, for example. Are there any other useful guidelines to work with? For example:
1) How big / small should I make things to let the user have a large enough 'target area'?
2) How can I get the file onto the iphone? Would the user have to drag and drop it via USB?
3) What size of fonts can I use before it gets too small to read?
etc etc. I don't actually have an iphone to test on, which makes this a little more problematic.
Thanks for your help!
I don't know about other smart phones, but the only way your file is going to get onto the iPhone is via the web browser, email, or a custom application that you write. There is no general mechanism for uploading files to the iPhone.
It's surprisingly easy to read even fairly small text on the iPhone, and the gesture-based zooming makes it very easy to zoom in and out.
If you're going to provide your documents through ASP.NET you might want to check this out:
http://mdbf.codeplex.com/.
It allows you to detect what kind of smartphone did the request, you can then check out the capabilities (screen-resolution, color-display, screen-pixels height... etc.)
Most mobile browsers render XHTML-MP (XHTML Mobile Profile). You can get away with rendering that.
iPhones (and other WebKit phones like Android) support the viewport meta tags which can make the experience more tailored to that phone screen size. You can learn about these in the iPhone web page creation docs from Apple.
If you are really interested in supporting a wide range of handsets, you should look at a "multi-serving" technology like WURFL, which will let you abstract a lot of the complexity away from supporting hundreds of handsets. It's sort of yesterday's technology though, since modern mobile browsers render most web pages just fine.
I'm not sure how current this is, but Yahoo says that one of the restrictions for an iPhone is that it won't cache files larger that 25k uncompressed. This doesn't affect your display necessarily, but it could affect your performance and so you may want to take it into consideration for your design.