Making your forms remember their values

One of the things that all of the forms we’ve built so far have been missing is something that virtually every browsergame worth its salt has: inputs that remember their old values.

You can see this in action on virtually any website you visit, whether it’s a browsergame or not. You type some text into a box, hit the ’submit’ button, and then when the new page has loaded, if that input area is still there, it will still have the values that you entered earlier. This is a really nice feature, that’s really easy to implement.

All you need to do is set the value attribute of your inputs to the variable that stores the information sent to your page.

Let’s say, for example, that in your PHP page $_POST['username'] has the value that the user typed into the ‘username’ box. To set the value to that, all we’d need to do is put value=’$_POST['username']‘ inside our HTML code that we are outputting, and make sure that it’s in a location where the value of the variable will be interpolated into our output.

If you’re using a templating system, this (usually) becomes even easier – under Smarty for PHP, you can use something like this:

<input type='text' name='username' value='{$smarty.post.username}' />

If you’re using Perl’s HTML::Template, you can use the associate argument in your constructor, with a CGI object:

my $query = new CGI;
my $template = HTML::Template->new(
		associate	=>	$query,
	);

And because the CGI object has a param() method, HTML::Template will just automagically store the values into any area where you’ve defined that they should be displayed, like so:

<input type='text' name='username' value="<!--tmpl_var name='username'-->" />

And that’s all there is to making your forms remember their values – a simple change that will help keep your users from getting frustrated with using any of the forms in your game.

Wish there was more?

I'm considering writing an ebook - click here.

.

Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Wednesday, May 21st, 2008 design, frustrations
  • Mark,

    You're definitely right on that point - according to the w3's stats, something like 95% of browsers have Javascript enabled.

    I would just caution against becoming too reliant on Javascript - while it's nice, there are still some users who choose to disable Javascript simply because they dislike it.

    I agree with you from a UI point of view, however - Ajax-based forms are definitely a lot nicer to deal with from an end user point of view.

  • Mark Little

    I kind of agree with the increased dev time allthough the use of an Ajax framework would make this minimal. For the benefits of making the UI slicker and not having the page fresh I think its worth it.

    I think most people have JS enabled these days. If they dont I doubt they would be able to play many of the top browser games or would at least have a reduced gaming experience in some way.

  • While Ajax is another way to make your forms remember what was put into them, it takes a bit more development time to make sure that they work for users with and without Javascript - by using this method, it doesn't matter whether a user has Javascript enabled or not.

  • Mark Little

    Yeah this is the way I used to do it until I started using ajax,JQuery in particular to do my form submissions. As theres no page refresh theres no need to populate the form fields. Makes the UI a bit slicker IMO.

    Mark.

blog comments powered by Disqus

About

Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.

Sponsors

Got Something to Say?

Send an e-mail to luke@buildingbrowsergames.com, or get in touch through Twitter at http://twitter.com/bbrowsergames