I've just starting reading about responsive design and I want to start learning more and more about it.
The first thing that has occurred to me is how to actually view your work in different screen sizes.
Is there a standard tool that people use on there computers to simulate there work on all different devices?? Or do you just check your work on the different devices??
Currently I've just been moving my browser to approximate sizes and it feels really unprofessional.
In Chrome, if you press [F12], on the top left corner, you have an icon which look like a mobile phone, then in your page, you can select the device model, and the screen resolution
Related
I had very simple appication written for old (24x80) terminals
working in production company. My client ask me to transfer it
as a web application and I use ExtJS 4 to do it. It looks like
this:
and its working on pc stations without any problem.
But next question of my client is to modify this application to
work also on tablets and smartphones. And only problem we see
is proportion, on smartphone this screens are to small. What is
the best way to do it? How can I resize fields and fonts and buttons depending on screen size?
What you need is a Responsive Application.
The problem is that the responsiveConfig was introduced in ExtJS 5.
So if you cannot move to extjs 5.0 or above take a look at this answer.
Another aproach is to use multiple instances for the view. Create three different view instances, one for desktop, one for tablet and one for mobile, keep the same Controller, Model, Store etc and when you initialize your application display the correct view according to the screen size.
I am using a script from http://detectmobilebrowsers.com/ to detect whether a site is being viewed on a mobile browser.
If the site is on a mobile browser, I show a pared down, simple slideshow. If it is a regular browser, I show a whiz-bang super slideshow. I'd like to optimize my images, making them as small as possible on the mobile slideshow. My mobile slideshow is responsive, so it will shrink to fit in whatever window, but I don't want to make it any larger initially than it absolutely has to be.
Does anyone know what the maximum width is on the current array of mobile browsers? Or rather, the maximum width of mobile devices that are detected with the http://detectmobilebrowsers.com/ script?
BTW, I'm not asking how to detect the width once the page is loaded in a browser.
Thank you!!
Edit....
I think you guys misunderstood my question. I AM using max-width:100%. My images DO scale to fit any screen-size. And, I DO determine whether to show a simple slideshow or a complex one. Here's my logic:
If the user is using a mobile device (based on the device detector)
show a simple slideshow
Else the use is NOT using a mobile device (based on the device detector)
If this is a small screen (based on media queries)
show a simple slideshow
Else this is a large screen (based on media queries)
show a complex slideshow
End If (based on media queries)
End If (based on the device detector)
Why bother using mobile detection at all? Because even though for small screens I am only showing the simple, low-filesize slideshow on small screens, the images from the complex, image-heavy, high-filesize slideshow ARE STILL DOWNLOADED (http://cloudfour.com/examples/mediaqueries/image-test/). My media query determination of which slideshow to show doesn't save the user from having to download the images of the slideshow that's currently not shown. It's only used because the simple slideshow looks better on small screens than the complex one. Using the mobile detection screen makes sure that images that aren't shown, aren't downloaded.
Why do I care what the maximum width is on current mobile devices, when my images are set to 100% width and will scale down to fit any size? Because a 900px wide image has a larger filesize than a 600px wide image. If I know what the max width is that the image needs to be, I can save the slide down to that size initially, saving some additional bandwidth. Have you guys ever viewed a slideshow on a mobile device? Slow!
I would really appreciate if anyone can point me towards the proper stats. I googled, but couldn't find what I needed.
The answer is almost certain to change as soon as you deploy the software.
It also depends on whether you mean pixels or screen-resolution-pixels (the Retina displays define them differently).
Perhaps it's best to stick with detecting mobile browsers (if you don't like the scripts you're using, see , e.g.:
Detecting mobile browsers on the web?)
and then let users opt into higher-rez images.
Alternately, you could try to detect bandwidth, which is really what you're optimizing for; 'mobile' is just a proxy for this, and only moderately correlated with it.
I'm retro-fitting a website for Mobile First Responsive Design (MFRD). My question is - how far do you go with the "Mobile First" part?.
For example - on the homepage I plan on having a list of upcoming events, say 4 or 5. On the mobile version I thought 2 would be enough to save screen real-estate. Should I load the other events in dynamically for the larger views, or should I just hide them since it will only be a few elements anyway?
Loading them dynamically for larger sizes means I have to attach an event to the window resize which typically gets fired every pixel. Even though I can offset that with Timeout, that's still a lot of client side checking is it not (even though it's not like users are constantly resizing their browsers).
I mean, even though you're designing for mobile first, you also have to consider the larger sizes right? Obviously larger JavaScript libraries and other assets that are needed for larger only you want to pull in later and not load for mobile - but how crazy do you want to get with the bandwidth saving?
What is the target market for the website? Are you making a completely responsive website that encapsulates smartphone to desktop? Or are you just concentrating on smartphone to tablet?
Mobile First really just means start your styling and content views at the smallest form factor and work up as the device dimensions get bigger. HTML, CSS (media queries) and jQuery all play a part to expand the UI and manipulate (show/hide) content elements as the browser gets bigger.
Take a look at Smashing Magazine, their responsive layout is one of the most extensive I have seen so far, it will give you an idea of how far you can take the MFRD or DARL (Device Agnostic Responsive Layout) methodologies.
We are building a Windows application in .NET and one of its requirements is touch screen monitor. Other than that, it's a normal windows form based application. But except for making UI items little bigger for touch, I can't find anything I as a developer need to do for the requirement since touch screen is basically mouse operations. Am I missing something?
No, you are not missing anything. Do get the actual hardware hooked up so you can test it, "little bigger" is invariably underestimating the problem of fat fingers. Everything should work from a single click, right-clicks are horribly impractical, double-clicks are best avoided.
The only other thing you'll want to do is go into the Control Panel + Display applet and change the size of standard Windows UI elements. Pick a large window caption font if you want to allow the user to drag or close windows. Make the scrollbars at least twice as wide. And the menu and message box font. Go in the Mouse applet to increase double-click range and time if you want to support that.
If you do not need touch-specific event handling I think it's all you have to do. But touch means more than that and you may want to support it in a better way: http://archive.msdn.microsoft.com/WindowsTouch/Release/ProjectReleases.aspx?ReleaseId=2127
We have a mobile web site that requires users to enter a specific time value--basically in hh:mm form. We're having a great deal of difficulty with the consistency of displaying and entering time from various browsers.
In looking for existing examples, we keep encountering various sites that allow 'ball park' values for minutes--so for them, a dropdown with 15 minute (for example) increments is fine--but a dropdown with 60 values is ridiculous on any platform, mobile especially.
The HTML5 < input type="time" /> isn't getting us there. A standard text input isn't either, as it tends to cue the device to show the alpha keyboard, which doesn't have numbers on it. The HTML5 type="number" almost works, but for some Android browsers, which don't have the colon (:) on the numeric keyboard.
I'm well aware that we're in the land of chaos with mobile browsers, but does anyone have a good idea of what might function well for both Android and iPhone?
Note: I've tried googling, and checked out various jQuery plugins, and none provide a good user experience for mobile--and many are poor even for the desktop. Ideas?
I don't particularly like their approach, but I believe the Any+Time date/time picker would work reasonably well on a mobile device - it can be positioned statically and the aspect ratio and button sizes look Right.
That said, testing it on my iPhone shows that a few kinks need to be ironed out. Notably, after tapping a button in the picker widget, the "hidden" input field the picker populates is focused and the view moves around and the onscreen keyboard pops up.
I hate answering my own questions here, but it looks like Mobiscroll comes closest to solving the problem for our users. We also looked at the jQM-DateBox but felt that our users would not be comfortable with the hour value changing automatically when you roll forward past 59, or backward past 0.
In addition to this, we did evaluate using a jQuery Mobile select list on a standard dropdownlist, but it felt wrong as we used it, as it essentially pops a div on the page, and scrolling through that moves the entire page quite a bit. I think that one would be great for a few items, but not applicable to our user base.