I have a couple of concerns, I'm busy building a normal .mobi site for a client, so basically how I understand this is keep it simply since most phones do not support JavaScript and have a small screen etc. So I build a mobi site using only content and basic links. Now my question is how do mobi widgets work on a mobile site? I've googled and could not find a answer? Is this possible at all? Since these small sites are meant for normal entry level phones and not smartphones?
.mobi is a domain suffix generally used to identify that the content is specific to mobile devices. It doesn't imply any association with Widgets.
Mobile widgets are generally specific to operating systems, and their definition varies across mobile OS's. Nokia Web Runtime Widgets for example use the webbrowser and provide access to device specific API, but it is native to S60 and needs to be installed on the device. Not what you or your client want here I think.
You have couple of options for developing mobile web sites. Have a look at the answer I gave here. It may help point you in the right direction. Search also for questions related to DeviceAtlas, who also provide similar API to WURFL.
Worth also taking a look at this answer.
Related
We have a requirement to build app with as much common codebase as possible, that works on desktop and mobile platforms (Android, iOS, Windows Phone). Also, the app on mobile platforms should act like an app (so not mobile-friendly website), with access to camera, position, and an icon.
Having looked at all the options and finding some or the other quirks, I decided on having webapp/site on browser and PhoneGap to base the mobile app on.
Now, as far as my understanding goes, sticking the codebase of browser webapp/site in Phonegap base structure should work for the mobile app. Of course, some minor changes may be warranted.
However, I also saw that relying only on phonegap and barebones HTML5 tech (without any UI framework) would need a lot of time and would be tiresome.
So I looked around for a UI framework and found - JQuery Mobile, Sencha Touch, Kendo UI, etc. jQuery Mobile, while could work in desktop browsers too, would not give me a grid-like system to position elements. The rest of them seem to work only on mobile platforms - they did not boast about it working/scaling on desktop browsers.
So, is there any common library/framework that can provide - CSS animations, grid-like system for positioning, etc.?
It's not an "answer" so much as an idea for a method. Perhaps try creating what you need from a desktop perspective first using bootstrap so it's mobile first. Then maybe make use of something like jquery mobile for the bare bones navigation and structure in the app. You can then pull in your page content via ajax using the same code/layouts from your "desktop version" (which will of course have a mobile friendly view/layout since it's written using bootstrap).
You'll likely have to either create an api for serving up the content for your app or else find some other way to differentiate the app from the desktop site on the server side so you know where they request is coming from, but it seems do able.
After some testing and verifications on browser and phonegap, I chose the following combination:
Yahoo's purecss library for grid system and basic widgets. Its awesome with the only pain that Google Search on it gives ambiguous results.
Reactjs to manage the view logic. This was the biggest pain in my previous project having only used jQuery, turning my whole project into a huge jQuery soup. React is extremely clean compared to that.
superagent probably, for AJAX requests to fetch server data. Extending this, I haven't yet decided to employ a model-like library that handles the state; may be I dont need one. I will decide as the project moves on.
hand-coded CSS with some common sense so that I learn something and dont waste my time in finding an all-in-one library. _The only necessary rule here is to weed out older best practices when you are looking for something. For example, in order to center something, the transition method is the best technique.
This may be opinionated or whatever, but I think its a fair question to ask.
So everyone at my job is like onboard with HTML 5 and whatever. I think its good to have this functionality possible in a web browser...
HOWEVER
For every different device wouldn't you need to support different versions of your HTML 5 application? Is that so much better than just programming a native application? Is the only benefit in this type of usage the fact that you can create one application with essentially different CSS/JS files?
I don't really understand why you wouldn't need different sizing libraries for, say, a tablet vs. an Android m/h-dpi device vs. an iPhone. They are all different, shouldn't the browsers render differently on those devices as well?
I know HTML 5 apps have features that allow it to act like a native app, but if you would need to resize your app for every device is it normally worth the tradeoff?
What is so good about Mobile HTML 5?
It's a buzzword. Buzzwords make marketing people happy.
For the rest of this answer I'll assume you mean "What is so good about HTML 5 when it comes to mobile devices?".
For every different device wouldn't you need to support different versions of your HTML 5 application?
No.
Is that so much better than just programming a native application?
Even if it was the case, it saves having to port the application to a different programming language and GUI toolkit for each device.
This is a great overview of why HTML5 is a good thing.
http://hubpages.com/hub/HTML5-is-Here-Now-HTML5-Benefits-for-Users-and-Developers
HTML’s layout system (which hasn’t changed in HTML5) is designed to work on different screen sizes — e.g. block-level HTML elements, by default:
take up 100% of the width available to them
are as tall as required to fit in their content — browsers are expected to offer scrolling so that the user can see all of the content
This is why you don't need different sizing libraries to view web pages or run web apps on either different mobile devices, or traditional desktop computers with different monitor resolutions.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am developing a web application (meant to run work as a rich client and able to afford requiring any (even nightly build) version of Firefox of Chromium).
The application interface background is meant to be transparent (showing underlying windows or desktop). How can I achieve this? Following standards does not matter but would be nice.
Primary target platform is Linux.
UPDATE addressing comments and answers received to the moment of 2010-07-07T01:44Z.
Technically it's nothing about code interaction and breaking the "sandbox". It's about window composition. I even think it can be implemented pretty easy in a compositive window manager without a browser even knowing of this - just replace some useless colour (for example "fuchsia" was widely used for this during Windows 9x age) with the underlying layer content.
Politically, this can and should be a restrictable function (like local file and webcam access, for example), which can be allowed for trusted intranet applications (local web-tech-based rich client applications seem to be a trend beginning - Firefox and Chromium implement more and more features to facilitate this) and forbidden for unknown 3-rd party websites (but this would require more complex interaction between a browser and a window manager).
The reason why would I like it is that I want to build a cross-platform (Linux, Windows, Mac), zero-install, fancy-looking rich client application (not meant to be served as an Internet website) with web technologies (like HTML5, CSS3 and JavaScript). I even will probably seek to use some browser-window-less tech to run it (I've heard about Mozilla Prism and XulRunner, KDE and Windows offer to use HTML for desktop widgets, Chromium is meant to offer something alike, etc.)
This is not possible "currently", but there's no technical reason why a browser couldn't provide a proprietary API for this, using non standard html/css/js.
However, that's what it would take, a browser to actually implement this functionality and then expose it as an API, and even then it would be browser specific.
UPDATE (as some people have perhaps misunderstood my answer???):
I'm giving technical context to the question. Of course noone's ever going to implement this, but I'm saying it's technically possible.
Also, doing this would not break the sandbox model. The browser itself (forget an API for a second) could implement transparency any way it wanted. Once it that it could hook it up to it's Javascript engine, and create a stupid call: Chrome.Element("").WeirdTransparency()
UPDATE to Questioner's Update:
to your point:
The reason why would I like it is that
I want to build a cross-platform
(Linux, Windows, Mac), zero-install,
fancy-looking rich client application
(not meant to be served as an Internet
website)
AIR kinda covers 90% or your requirements. It still needs a small install, but apart from that, you're running...
This is possible in Electron. By setting a transparent background on the body.
I'm sure browser developers would need a lot of "inspiration" - aka $$$ to do this. It's currently not a feature that a whole lot of people are looking for.
Since standard compliance is very high on the priority list for all browser developers, making this out of the box would be a problem. Namely because there is no CSS/HTML support for it, and the standard is to have a white background. This means that they would need a custom "flag" somewhere in the markup to tell it to switch off the white background.
This would be exclusive to the browser that implements the "feature" and anyone else using any other browser would not be privy to the it.
Somehow you can get the background image of the desktop, set it your html background, and code any app in it. when you do this concept with active desktop in desktop configuration, I get to see this. ( I maximize the web page and lock it - to make it feel like my desktop )
For getting the background, I am putting the location of that in my PC right now. But I think there should be some programmatic way to do it.
This works for our local desktops. But the idea you are talking about, you definitely require Prism like thing. But Firefox looks like it stopped that project for all. (I keep the dump of it in my PC, though). So Recent users would not have prism even if you guide them to install it on their PCs.
And then, This works if the image is full sized to fit the desktop. Otherwise, We have to repeat it, and the whole desktop looks absurd. I often try to write AIR ( Adobe RIA platform for the Desktops.) apps for my taste of eyes.
I think you should try learning Adobe AIR. In fact, it supports all open technologies. I am not any Adobe employee though :) in case you think I am promoting AIR.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
My website will be basically selling services; will my SEO ranking still be affected if I embed the Flash site in a blank html page? I am at that critical point where I am ready to upload the site but I am just having second thoughts about the ease of doing business with Flash.
Ignoring the SEO implications of an all-Flash site, unless you're building games, or I have an extremely strong desire to buy what you're selling, I will turn back immediately if I find a website built entirely out of Flash.
Nothing against your programming skill; I just have rarely seen such a site give me what I want. The name is often apropos.
Search engine crawlers can't crawl flash sites, so your SEO rankings will be based off the non-flash part (the blank html page). Personally, I also don't really like the user experience of a flash-only site.
Google and Yahoo! have added flash crawling functionality to their engines recently.
http://www.adobe.com/devnet/flashplayer/articles/swf_searchability.html
From a SEO perspective you're fine on that front. Still..your page will need a DOC TYPE, Page Title, etc to remain SEO compliant.
IF your target market is users browsing your site from a laptop or desktop you should be fine. You may want to include a flash-free option for users accessing your site on a mobile phone or with javascript/flash disabled.
For example, You can run a browser sniffer to redirect any user agents accessing the page on Safari via an iPhone OS.
Other than that Flash does offer some nice flair to a site. If you can give alternatives to users that don't like the application then I say do it.
It can certainly be done well. I've seen some pretty cool Flash-powered stuff being run by some pretty big-name companies, do a search for HP's Photosmart page for instance.
Look: there's a lot of information out there about Flash and SEO, and much of it is out of date. Google rolled out "official" flash support about a year ago, and they've been refining it ever since. Google will index your Flash site, but exactly what gets indexed is a bit of a black box so it always helps to have HTML alt-copy.
Never, ever build a full-flash website without using SWFObject for embeds and always try to use SWFAddress to enable Flash Deep-linking. There are ways to make this work and work well - a lot of people don't know that and have a deep-seated hatred of all things Flash because they were irritated by Splash pages in 2002. There's nothing to be done about them.
But if you want to use Flash, go for it - just do a lot of homework and test your work.
Whether or not it's business suicide depends on how much of your revenue is dependent on getting referrals from search engines. Your search engine ranking will certainly be affected if you have an HTML page in which you simply embed some flash.
Could you implement an alternative more static site, by scraping the main content from your flash?
all web applications should be made from the point of view of accessibility, no matter what the scripting language used at the time. If you use a nice script like SWFObject then you can populate your page with "alternative content" to the flash page which the search engines will crawl. this will also allow any browser that doesnt have flash to have a look at the website, even if you dont make the whole thing as "pretty" in HTML.
two birds as they say.
I don't know whether you've considered this or not, or whether it applies to your circumstances, but you might lose out on business from the visually impaired. Unless I'm mistaken, I don't think there are any screen readers that operate on Flash.
I think it depends on what kind of business we are talking about.
For most, I would say don't do it!
But there are ome kinds of sites where I think it is appropriate, if done very well. For example if you are in the business of art or design, or are showcasing a product/service where art or design is key.
As an example:
Volkswagon's GTI Project (a large part of what cars are about is design)
Flash has fallen out of favour the last few years with a lot of people. Initially it was because search engines didn't crawl it but these days it's mainly because 'flashy' effects can be done with javascript engines like jquery, scriptaculous or mootools.
Having said that I can tell you that nearly every business customer I go to still wants flash on their site and most casual web users don't give two hoots what a site is built like as long as it works, is fast (something kinda tricky to do with flash) and is what they want to look at.
I say go for it and see how the site does! I'm sure if you use analytics for a few weeks you will know whether your site is doing well or not.
Best of luck with it :)
For some reason Motorola made their new Droid site all in Flash.
This is a good article about how dreadful it is, and the drawbacks:
newmedia article
There are a ton of good reasons to use Flash sparingly. It's good for what it does well and dreadful for entire sites.
Ok so first of all, perspective, my primary domain is Flash and system architecture, I and the company that I work for at present are all about creating online 'digital experiences', engaging online content.
This is NOT applicable to selling services, e-commerce, and general information based sites, as much as it pains me to say that. There is current a massive backlash against flash due to the arrival of javascript effects and the canvas tag, I'm going to be bold here and say that anyone who thinks they can replace x years of plugin development and and media experience by giving html/javascript devs a div they can draw into are simply misguided (and you can show me all the chrome experiments you want but its still not going to be pixel bender or native 3D support).
So with that said, in this climate you've got to play to each formats strengths, you want slick, stylised SEO'd content that is accessible and concise, html with progressively enhanced javascript is a no brainer. You want a web app that people can use easily, search and build a micro-community around then googles GWT (other js frameworks are available) is the way to go. For everything in-between and beyond theres Flash.
I'm not giving Flash a kicking (it's my lively-hood after all), far from it, in fact I'm actively encouraging people to use Flash only for the kind a digital master-pieces it was made for, if you can do it in HTML, why would you do it in Flash? Sure in most cases it actually works out lighter than JS, and it's cross-browser compatible, but these are small issues that will only be ironed out in time, HTML was designed for the web, Flash was designed as a plugin.
In coming years we will see Flash on a multitude of devices with the open-screen project and the iphone-flash cross compiling, it is becoming a platform for multimedia development in general, where-as the web is becoming more service orientated platform, web apps running off searchable indexed content in the cloud. If your website is intended for the web, then make it for the web.
(Just realised that this was a bit of a rant, apologies)
If you created a web site with Flash, user will not be able to use basic browser functions and extensions such as searching, spell checking, sharing a particular page via Twitter, etc.... (And cannot access from iPhone.)
Depends on the site in question. If its just displaying marketing collateral or case-studies then a "flashy display" would be fine. Have seen couple of such websites in the past and the better ones have impressed me.
You should also consider how frequently content would change and how it impacts your design in Flash vs say design in html. The search engine ranking aspect also will matter.
You won't get any business from me.
Nothing says 'amateur' on the web like pointless Flash.
With today's modern mobile phones, is it still worth programming the mobile version of your site in WML?
Most mobile browsers even a few years old can manage to do okay in regular HTML. With WML, you are obviously given more control over what is displayed and what isn't with less fear of it not working on a particular device, but today, with all the advancements in mobile browsing (iPhone, Android, etc) is it really best to go this route?
I am wondering if the best option is instead to go with an HTML4 document that has a few more bells-and-whistles than what WML can do, but not quite the glorified super-spectacular AJAXified interface that one might design for a modern desktop browser.
Yes, I know, this is objective and has a lot to do with site audiences and how far I want to extend support. To put a scope to this question, my main concern here is whether foregoing WML for HTML is going to devastate a huge chunk of my audience and leave them completely stranded.
Edit for Dr.Dredel's point: the site would NOT be used by an SMS campaign or anything of the sort. The website is an event booking site for pickup games for hockey. Some users currently browse to it on their mobile phone to sign up for different sessions.
Do both. There's no reason to ignore the browser string and display the same markup for every device. WML is simple enough that you can use template styles (which you should be using already) to provide a custom experience for all your useers, regardless of the device they use.
Those with bare cell phones will get a usable interface that meets their needs, while those with PDA phones get a nicer interface with more options, and those with the iPhone might even get the eye-candy iPhonophiles really bought their phone for.
If you can't do that, for whatever reason, go with the least common denominator to gain the greatest visibility and usage - that's what's going to make your site successfully and useful enough that you can afford to use a real templating system and move towards the ideal state. This is likely WML, although even older phones were ok with very simple HTML, it just has less control and ease of use features.
-Adam
I think the primary problem with this question is that it fails to identify what exactly it is that you're offering your users, which would instruct who, demographically, would find your site.
If your site is arrived at via SMS based links (through some global marketing campaigns) then you need to try to reach the widest possible audience, since almost all phones will allow a user to click within their SMS client and then launch whatever browser option is on the that phone.
If, on the other hand, you have a site which needs to be browsed over to manually, then there's a reasonable expectation that most people simple won't bother on their crappy pseudo browsers, because even the act of inputting the url is a fairly large hassle.
I would say that if you're dealing with option B you're pretty safe just delivering an experience that is tailored for a browser like Netscape 1.1 (just dust off whatever you were doing in 1995 and you're good to go! :)
The vast majority of mobile phone users have a phone that was purchased within the last few years, and any users that have a phone older than that are unlikely to want to use the internet from their mobile. Personally I think you would be better of making a high-end 'AJAXified' site with all the bells and whistles and a standard XHTML-MP site that would be accessible to most users.
You should use XHTML-MP for mobile versions of sites. You'll get better continuity with the non-mobile version and it will work with more (particularly newer) devices