TinyMCE or other WYSIWYG Editors for Mobile Devices? - mobile

Is it possible to use a WYSIWYG text editor (especially TinyMCE) for a mobile device or is that not supported yet? Will it ever be supported?

This weblink Compatibility table for support of contenteditable attribute in desktop and mobile browsers. will give you a clue about this issue.
I was looking for the same thing today, so I thought to share this link with you.

It is possible to use it on a mobile device, but the javascript functionality in those browsers is limited, so not everything is possible (own plugins and several interactions with own CMS i.e.).
Keep in mind too that heavy js-usage on a page will slow down all its functionality on mobile devices cause the system is not as powerfull as a personal computer. I had the problem that the js overhead of a CMS delayed js-functionality in the browser so that clicking checkboxes and selecting input fields was almost not usable.
It might be necessary to redisign the whole CMS around such an editor to run fast enough to make it work.

Related

How to define mobile website on server

I found this great tutorial that explains designing a mobile website and I've decided to give it a try. My question is how do I define mobile pages on my server so that they do not conflict or show up on the desktop version of my site. For instance, in the video they use index.html, but since I obviously already have an index.html on my server how would I get a mobile device to direct to a "mobile index" page?
You would need to employ browser or device detection techniques. A few ways you can do this is via JavaScript, PHP, or if you're using Wordpress, you could use a plugin.
CSS-Tricks has a nice little snippet that may be useful to you:
http://css-tricks.com/snippets/javascript/redirect-mobile-devices/
Or if you want to learn the PHP or WordPress side of things, heres another good link:
http://mobile.tutsplus.com/tutorials/mobile-web-apps/mobile-browser-detection/
Its not a server thing. Try messing around with the user agent to detect a device.
Another option is detecting a screen resolution (small sizes > mobile page, big sizes > desktop page. It really depends on layout though).

zurb foundation 4 mobile vs desktop content

I'm a big fan of Zurb Foundation. They just released Zurb Foundation 4 which was redesigned to be mobile first. I'm fairly new to responsive design taking into account both mobile, tablet, and traditional desktop experiences. I'm trying to wrap my head around how best to manage my site's content for these different devices. With Zurb Foundation 4, you can hide or show content based on small, medium, or large device sizes. So, it seems with Zurb's approach you drop all of the content down to the device and let the CSS decide what content to show depending on device (this is responsive design).
My question is why do we have to drop all of the content to the device? That seems like a waste of processing on the server, a waste of bandwidth, a slower experience as the browser handles the content some of which may never be shown to the user because of the device they are using. Am I missing something? Wouldn't it be better to go back to the server and let it send content to the client that's appropriate for the device type? Shouldn't we be concerned about mobile user's data plans and not send down content that's not appropriate for their device type? All the examples that I've seen on responsive design has content for desktop and mobile/tablet downloaded to the client which seems to be a waste.
I'm developing a time entry application that has a different user experience based on the device type. Desktops (when in full screen) have a more detailed data entry experience whereas mobile/tablets have a different experience because of device real estate is smaller. I'm developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the "smaller" mobile/tablet version. Is this appropriate? I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
Am I on the right track with my jQuery approach? Am I missing something regarding responsive design and needing to tailor the content to the device? Any ideas, suggestions, and guidance is appreciated. Thanks.
Mobile First with Zurb Foundation is basically a philosophy change by the Zurb team and if you want do develop a responsive site and not take a Mobile First approach then I suggest using Foundation 3 which is still available and fantastic. There is a book that I am reading that gives a great pitch for Mobile First, called Mobile First by Luke Wroblewski who is also listed as an adviser to Zurb.
here is an article by the same author that might be interesting:
http://www.netmagazine.com/interviews/luke-wroblewski-mobile-first
Basically: the premise is that you start your development and design for a mobile, meaning basically an iOS or Android style browser and then add features.
So instead of starting with a desktop / tablet experience and removing things as was commonly done with .hide classes in foundation 3 and could still be implemented in this way with foundation 4, they suggest using .show classes to add additional content.
This can be taken way further by using Compass and Sass Mixins. There isn't a lot of great documentation on how to do this, but you can basically keep your markup semantic, apply an id rather than a class and use the mixins to apply it to that id. There are advantages here in speed traversing the dom for an id vs. a class so it can be a good way to go.
Note: foundation 4 is using the drop in replacement (there are some limitations) for jQuery called Zepto. You can replace Zepto with jQuery if you really need it in foundation 4 or use foundation 3 instead. Zepto is much more lightweight and thus suited well for mobile.
As for it being faster by using jQuery to async load the data (I am assuming) based on the size of the browser, that is one way to do it. I am not sure if you are going to have a huge speed increase here. There are many strategies, pagination, async loading more data on the fly, and it depends on how you arrange the UX / UI around that data.
There are also many other issues such as caching resources, CDN, etc. that are typical in front end engineering that might give a faster load time. One resource you can check out related to this is ySlow.
There are also many design patterns such as off canvas slides, the 3 line (hamburger menu), loading more data on scroll, stateless apps, that can allow you to have the same functionality in a mobile app. If you go stateless, after the initial page load other pages should appear to be almost instantaneous.
I think the question here is more philosophical, in do you need all of the features, which is one thing that I believe taking a Mobile First approach is trying to approach.
Another thing to think about is the perceived loading time. I think I read about this is Seductive UX (another great read) but the faster you can get the page up with a loader or spinner, the faster it is perceived to be loading, even when in actuality it can be loading slower.
As a final note, if you plan on using foundation, you might look into using jQuery/Zepto with Modernizr to pull from the same media queries foundation is using. That way you don't duplicate or create something that is inconsistent with the rest of the responsiveness.
I'm developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the "smaller" mobile/tablet version. Is this appropriate?
It doesn't sound like a good approach do you take orientationChange in to account?
I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
If you are on most tablets visiting the website in portrait and change to landscape you'll have to download the >768px UI after already downloading the <768px UI.
The mobile first approach in zb4 (with media queries) allow you to prevent stuff that belongs to big devices to be downloaded in to small devices. Basically you start with mobile styles and if the device meets the conditions you set on your mediaqueries (you can have much more breakpoints than the zf4 framework gives you by default) then the next rule jumps in.
I have worked in several 'responsive' projects even back in the pre-mediaqueries days were I use javascript to measure windowsize
Regarding javascript and like #powjames3 said zepto is much lighter / faster than jquery and if you could write your own javacript functions will be much better than using a over-bloated library.
Nowadays I do mobileFirst responsive webapps and websites use a mix of user agent sniffing ( sometimes to decide what image src or script / style src to deliver), despite the decision of the user agent tests i always serve mobile first mediaqueries, and conditionally loaded content.
"As Ethan Marcote (and John Allsopp before him), were right to point out, the inherent flexibility of the web is a feature, not a bug."
Here are some resources that might put you in the right track:
User agent parse and detection:http://mobiledetect.net/
Tutorial http://www.html5rocks.com/en/mobile/responsivedesign/ that covers:
Why we need to create mobile-first, responsive, adaptive experiences
How to structure HTML for an adaptive site in order to optimize performance and - prioritize flexibility
How to write CSS that defines shared styles first, builds up styles for larger screens with media queries, and uses relative units
How to write unobtrusive Javascript to conditionally load in content fragments, take advantage of touch events and geolocation
What we could do to further enhance our adaptive experience
Hope it helps

Best practice for detecting and formatting for mobile browsers

I host a small web shop for a client who wants it to be easily accessible from mobile devices.
How do I detect if the user is browsing my site from a mobile device?
When I have done that, should I:
Check if the user has mobile device and then forward them to another site?
I think the advantages would be:
I can optimize layout from both sites for screensize
I can use different techniques in the two sites (eg. jquery mobile for mobile)
Use CSS for the different screen sizes => like on tutsplus
I think the advantage would be:
I only need one site but it seems to me heaps of work when talking about a small webshop
Ideally, you should try using jQuery Mobile page structure with your own CSS and JavaScript for non-mobile devices.
You can easily detect user's browser and conditional script includes as per html5 [boilerplate]:3
/* Grade-A Mobile Browsers (Opera Mobile, Mobile Safari, Android Chrome)
consider this: www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/ */
#media screen and (max-device-width: 480px) {
Main things to consider when aiming at iPhone users:
ensure there's no vital flash objects
on the page as it isn't supported by
many mobile browsers (yet?)
appropriate screen size (using
viewport meta tag)
keeping in mind that there's no mouse
cursors, meaning no
hover/double-clicks are available any
mouse dragging gestures are different
on touch devices
remember all pop-ups are open in new
tabs and won't be seen at the same
time as the main window, use
javascript modal divs as alternative
test all your javascript and css to
ensure everything looks and works the
same (Safari requires -webkit- prefix
for the newest CSS properties)
create a Home screen icon for your
website (a nice thing to have)
most of these things are covered here
take a look at Safari Dev Center for tutorials/videos/coding how to's etc.
There are several options but this is my favorite:
http://code.google.com/p/mobileesp/
Comes with a API in a couple of different languages as well
You don't need jQuery at all if you don't want to use it. We don't. Not that there's anything wrong with that.
Number 2 is the best option. If you create a site with mobile in mind first, it's far, far easier to expand and manipulate for the desktop than trying to shrink things to a mobile screen.
JQuery Mobile is currently in beta 1 right now. Beta 2 will be out within a month. It is fairly stable at the moment and you can gain a lot of knowledge about what is considered "best practice" from them. You can use media queries for screen sizes for different platforms which JQuery Mobile also supports.
http://jquerymobile.com/

Good mobile oriented GWT widget library alternatives

I've been developing a travel planning site - tripgrep.com - which is built on appengine, GWT and smartgwt, among other technologies. It is still early days, and the site is now working well on my development environment, which is either a windows or mac computer.
However, I am frequently talking up the website to my friends when we are at a bar or other venue, so I am standing there while they try to access the site via an iPhone, Android or Blackberry - I've witnessed all three. It has been painfully obvious that the browser based frontend takes a long time to download on a mobile device. I am pretty sure this is because of the javascript download for SmartGWT.
So, I would like to look at alternatives to SmartGWT.
What I like about SmartGWT is that it has a reasonable look and feel out of the box - I don't need to learn any design or css and it has an office application look. This is considerably better than the GWT built-in widgets, which just get a blue border. The better look-and-feel is why I went with SmartGWT early on. However, the slow load times are killing me on these mobile demos. So now I want a fast loading widget alternative that has good look-and-feel out of the box.
The features I care about are: tabs, good form layout, Google maps API integration, grid data viewing. If those are all available in a library that loads quickly on a mobile device, then that's the library I want.
Your best bet is probably just to use the standard GWT widgets and learn how to style them to your liking. SmartGWT's automatic styling is nice, but as you've noticed, it comes with a price.
Even GWT's standard widgets, which are lighter, could still be trimmed down for maximum speed, so if you're really adventurous you could roll your own light-weight widgets that do only what you need them to do.
You can try mgwt-also called mobile gwt...(available at http://code.google.com/p/mgwt/ )
You could write a wrapper for jqTouch... that would be cool.
Write a seperate View for your model, specifically for either a) mobile devices or b) iPhone speicfically (see "iui" f.ex.). That is the very best way to do it.

What is the best 'method' to do an online MOBILE Text Based 'App'?

With all the different mobile phone browsers and the mobile market being so diverse I'm having a hard time deciding on a way to create a text based online game for mobile phones.
I was thinking about using HTML / CSS / Javascript for front-end and Python CGI for server-side (with a DB).
Now this seems like a very obvious choice... BUT I'm having a hard time finding the "limits" to each one... by that I mean at what point will a popular web browser stop 'supporting' a technology. Like when it comes to HTML I assume you cant use HTML5 features in all popular mobile browsers... or maybe some allow JS but not jQuery... or maybe some don't allow some common CGI features or DOM is weird... I do not know.
I have read a few different tutorials on various mobile web browser development but nothing really helps to answer my question.
So what I'm asking is basically:
What languages/technologies do you recommend for a Text based mobile online multiplayer turn based browser game that will need to dynamically load a lot of info?(front front end to back end)
What are some common limitations between popular mobile web browsers I should look out for? I want to be compatible with all popular mobile web browsers.
One of the things to keep in mind is that there is a plethora of mobile browsers out there (Look here for details). So you are probably better off starting with iphone, android and blackberry and maaaybe opera mini browser support. These browsers have sophisticated java script support and you would be able to provide a good user experience. Later on you can work on supporting other mobile browsers.
Regarding your questions, if you look at these browser specs (and they are readily available on Internet) you will see that you will be able to use quite a bit of web technologies (HTML, CSS, Javascript, etc). That wont be a showstopper for you. Designing for a small screen, and a great user experience on small screens, that will make or break your game.

Resources