More specifically, when developing websites/web applications, do you cater for users double clicking on elements that aren't originally designed to be double clicked?
I know this sounds like a slightly off-topic question but it's something I've only considered recently and something I'm genuinely curious about. There are certain users that we all know that will double click on elements in the browser, in fact they pretty much double click anything on the computer to action something. Granted, these people are usually the less experienced - but they are users nonetheless.
I had an issue a couple of weeks ago whereby I was making an ajax request onclientclick of a button. Double clicking the button caused unwanted behaviour, so I've put the necessary checks in place. Which led me to thinking that maybe I should be considering this for all elements on a web page.
Is this something you currently code around?
We have a simple web form for making purchases, it just used ordinary form submission, no AJAX. And we found that some customers were accidentally purchasing twice, because they doubleclicked, or maybe the server was slow and they clicked a second time while waiting. So I put in some simple Javascript to disable the submit button after the click.
Related
Now this has come up a fair bit on here so I guess I'm looking for an explanation rather than a fix (though that would be ace), but Safari's back / forwards cache is horrifically greedy.
I've got an issue where a form submits, but loads an interstitial modal window before moving on to the form action page. On Safari the cache is so strong that the back button has the modal open still which is making my soul very sad.
I'm hacking around it by dismissing the modal and then submitting the form. On back the browser has a half closed modal (it's Bootstrap so it fades) which then just carries on dismissing.
Now I know about onunload="" but refreshing the page just seems crazy. The cache is a good thing and something you want, specially on mobiles.
I guess my question is:
Why is it so much more intense than say Chrome and is there anyway of forcing the browser to cache a state instead of just the last state?
Thanks
Hah, greedy is an understatement! Honestly though, 99% of the time, the caching design behind Safari is the ideal way to handle page transitions on a mobile device.
When you go from Page A to Page B, and then back to Page A, you don't want to burden the device (bandwidth, battery life) with fetching resources and assets, when you could just "paused" the state between interactions, and then "continue" it when you navigate back.
That's effectively what Safari Mobile does. They use a concept of Page Cache, which keeps the entire page live in memory, when you navigate from one to another. This reduces the need to fetch those resources, and allows for a snappy interaction when clicking back.
That's great and all...but it does lead to problems (such as the one you brought up) - Specifically, how do you distinguish between a page that was suspended and one that should have been destroyed?
Thankfully, WebKit provides a pageshow and pagehide event that tap into Page Cache. In addition to firing when the page shows or hides (similar to onunload), it has the nifty ability to indicate whether a page was persisted - or placed into the Page Cache.
While it's not a perfect solution, you could check the pageshow event for persistence, and then handle the modal more directly (since you know it was cached) like immediately hiding it.
If you haven't already, take a look at these two links here:
https://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/
https://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/
They do a great job explaining the Page Cache and include code samples of the pageshow and pagehide event I referenced earlier.
Hope this helps!
I have a page that has a RadMenu and a RadGrid used together. The RadGrid is used in client-side mode. This means that the loading, saving, editing and creation of new records is done via ajax. The grid seems to work fine but after sometime it appears that The menu dropdowns tend to be slower and after more use the entire page freezes. I am not sure whether it is this combo that causes this effect or either of the controls since a lot of js is being used to automate the menu dropdown and the ajax calls to the. This is the order in which the error is reproduced.
The menu control is located up above in a separate iframe and the grid is below in a separate iframe. This makes the scenario more peculiar since different js files are loaded in two iframes and there is no interaction between the two.
What could be the cause of the sudden freezing, a memory leak perhaps? Better still could it be a general problem when a lot of ajax interactions occur and other events are fired before the callbacks return?
On the video once can see that when the grid page loads everything seems fine, but after firing some events and performing some actions, the menu starts taking a lot of time to load. It reaches a point that it takes such a long time for the drop downs to display and eventually the entire browser tab freezes.
I have uploaded a video of the effects and here is the link:
http://megaswf.com/simple_serve/87153/
"Better still could it be a general problem when a lot of ajax interactions occur and other events are fired before the callbacks return?"
- that's most of your problem. Telerik's JavaScript is thrown together, just view source and check out how many scripts are on the page, as well as the inlineJS. Contacting Telerik couldn't hurt, but I doubt it'll help. If you have a float based layout, when you go into edit Telerik, the tools don't work because they're relying on absolute positioning. I had to find my own solution. Good luck.
I'm just learning about how to navigate between pages and tombstoning. I'm wondering if anyone can point me to some good examples that not only show me the basics of how to use Navigation properly but also good examples of more complicated and advanced navigation issues?
Some questions I have revolve around memory leaks when navigating to other pages and navigating back?
Is there a close page call, once the page has done its job (I don't want an instance of it hanging around after I'm done with it)?
Another question is how to I maintain state if the app gets tombstoned (still trying to wrap my head around that term).
Thanks!
There's no close page call, the OS automatically closes pages when they're backed out and releases used memory (so there should be no leaks here).
Some resources here that cover tombstoning and advanced navigation concepts.
Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and Few More Things That Are on the Way – Part 1, Part 2, Part 3
Introducing the concept of “Places” - Peter Torr's Blog
Redirecting an initial navigation - Peter Torr's Blog
I like thinking about WP7 navigation like a simple browser that only have back button. The Naviation model is based on stack pattern (Last In First Out), need to get through all to get back to first page. This is not what PC user are used to but in mobile world is one of the best solution.
You have to stick to this model and never ever do "go to home page" button - your app will not pass the certification for sure(there are some workaround with excetions but I wouldnt recommend that).
A lot of pages can get the user pissed that's why a good idea is to have 3 to 5 pages max. For instance, first page user picks what he is going to do, next page is login page and then for more complex interface use panorama and pivot control.
To the simple browser model add cookies. When your browser load a page it sets a cookie with some information, next you close the browser and when you go back to the page it can get the previous state from that cookie. Tombstoning is very simailar. - link. Some more info about tombstoning
Some questions I have revolve around memory leaks when navigating to other pages and navigating back?
What do you mean by memory leaks? you are working in managed framework.
Is there a close page call, once the page has done its job (I don't want an instance of it hanging around after I'm done with it)?
you do not have to do this. Page is destroyed everytime you go to the next page unless a thread is still working there.
Another question is how to I maintain state if the app gets tombstoned (still trying to wrap my head around that term).
Basically it's up to develepor to manage this. It is not mandatory but gives a nice user experience.
Another question is how to I maintain state if the app gets tombstoned (still trying to wrap my head around that term).
Use Isolated Storage.
You can have a look into Columbus MVC framework for WP7 source code (http://columbus.codeplex.com/) that I have published recently. Columbus addresses both Navigation and Tombstoning (provides strongly typed navigation with history and View Models that can survive tombstoning).
You know how sometimes you are on a good site and you click a button (like to submit a form) and the form doesn't go away, instead, the foreground becomes transparent and it contains a message of some kind, or another page. The message is at the forefront but the previous page is still mostly visible behind it - how do they do that? I'm assuming it's an Ajax-esque trick.
This is called a light box modal. There are quite a few JS plugins that can do this including Lightbox and the JQuery UI Dialog to name a couple. I just recently started using Fancybox and have been very impressed with its speed and configurability.
Here is a pretty good (not all inclusive) list of them:
http://spoonfedproject.com/jquery/extensive-list-of-jquery-lightbox-modal-plugins/
One way is to use GreyBox. I think this similar to the effect that you're talking about.
which of the following styles do you prefer?
An application which to perform tasks opens new forms
An application which keeps the various "forms" in different tabs
An application which is based on a PageControl and shows you the right tab depending on what you want to do.
Something else
Also do you have any good links for gui design?
From a programmers point of view, the PageControl solution quickly gets out of hand. Possibly too much code and certainly to many components on one form. (Originally this question was tagged Delphi, so I go from there.)
From a users point of view, the "opens new window" paradigm often is confusing. We people tend to think that we are able to multitask and handle many open windows and tasks, but we are not (we task switch at a loss of time like computers and add loss of accuracy).
Obviously this really depends on the type of application. But I would tend to a paradigm as Chrome and Firefox show in their latest incarnations:
keep the various forms in different tabs
let the user detach a tab into its own form (dock and undock via drag%drop)
add a good way of navigation
I implement something like an SDI as main screen of an application too. Look at something like "outlook style". Navigation, list of objects, object details in different panes, some additional panes like a cockpit. And then open a new window/form for certain tasks (some modal, some non modal), but short lived. After the email is written, it is sent and closes the window. But I have, if I am capable of doing so, the possibility to work on multiple emails at the time.
Look at the problem. If it has dashboard character, take "outlook style" or so. If the users are a wide spread, heterogeneous, non computer savvy crowd, use SDI or forms on tabs. If you write for programmers, you might go for multiple forms, just because we tend to think that we can handle it. And it works for multiple screens (hopefully).
MDI is the worst choice possible, in my opinion. There's nothing I hate more than having to resize a bunch of windows, or tile them or whatever.
Tabs are bad, too, especially if you have more than one row of them (or if you have one row but still have more tabs than will fit, and have to use some funky scrollbar or "more" button with them).
I would rather see the programmer think about the problem and just show me what I need to see based on what I'm doing as a user. Implementing the different user interfaces in your programs as user controls (as opposed to discrete forms) and then showing them or hiding them based on the current context is the way to go.
The Tabbed form is a good idea if you use a frame for each tab content. This keeps you out of trouble from getting too much code in one single form unit. Try to do the same as Google Chrome. I personally create a menu with the options that are actually frames that loads only when the user asks for it, so there will never be many tabs visible unless the user needs them all opened.