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.
Related
So I'm not really sure how to explain this but I will try my best.
I created a jsfiddle: https://jsfiddle.net/xghar755/2/
As you quickly hover over each text, you can see that the background color changes. This is just a simple div with a css hover property. Here is the kicker though, go to your address bar and type in any letter and you get a drop down of items, like so.
Now, quickly hover your mouse over the items in the dropdown. And then go back to the jsfiddle and hover your mouse over its items. You can tell that the chrome versions` background color feels more responsive. It's rarely noticable, but I can tell. Why is that?
Is this because Chrome's a Native application that doesn't rely on CSS or the DOM? If so, does this mean that native apps are generally more responsive in user interface applications? Thanks ~
Chrome is a software program running on your device. jsfiddle is, in part, a program that communicates with Chrome via the internet. Each transaction between the browser and jsfiddle takes tens of milliseconds, perhaps hundreds, and there can be a multitude of back and forth operations to serve one page and its in-betweens. In addition, Chrome is written in a language that runs in your machines native processing language while communication with jsfiddle is all interpreted by Chrome first, not to mention some processing is done on the jsfiddle server before being sent to your browser.
tl,dr; Programs running on your computer can do things a lot faster if they don't have to communicate with other programs over the internet.
I am working on a big application that relies on Infragistics objects to display info to the user (WPF, Infragistics suite Ver 11.2). Inside the XamDatagrid users can input some dates (internally it uses the XamDatetimeEditor) using either the keyboard or a calendar. Most of the times the calendar is there but sometimes, for no reason (and I've been debugging and checking exceptions) the calendars just disappear, specially when I reload the data (by pressing "Search" again).
I know there is not enough technical data nor code but I just wanted to know if somebody has faced similar issues with this grid/version and how (if you could) solved it.
Thanks!
I had my app working just fine a few days ago and then I noticed the first problem. I had to tap twice in order to make a button go to the next screen. Also happened to the checkBoxes. Had to tap twice to make them change.
But now it got serious. Since yesterday when I tap on a TextField the app freezes and then crashes.
The only significant changes I remember I did were 2: I uploaded an image for the App Icon and I edited the TitleArea UIID. I removed the TOP and BOTTOM margins. It also affected some of my label and button UIID, because now they don't show on the device
When I run the simulator, the doble tap also occurs, but the TextFields work fine and the Button and Label UIID look the way they should.
Any ideas why this happens?
I am right now working with old versions to try to determine the reason, but no luck so far. Thanks
Use a solid color rather than a gradient with the same colors. Gradients are slow and problematic across platforms so you are paying a lot for something that you aren't even using.
We'll need a better test case to reproduce crashing, I think that what you initially saw when you submitted the issue was a regression in the text input that we since resolved in the build servers.
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
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.