Specific search forms

Last week I described an overall layout of the calendar web application. It consists of a top search bar where we can input what we would like to see. For instance, the named days of a specific year or the calculation of a birth date from a death date and an age. In this post I will continue describing the design and elaborate on the drop-down search form I touched on last week.

Search form

The search bar is used to instruct the application what to calculate and show. In the simplest form we just input a year and the application shows a list of named days and when they fall in that year. However, we can also input that we would like to know the date that is some years, months and days before another date. Or we may indicate that we would like a date from one calendar converted to another calendar. If we haven’t used those features before or we use them rarely, it may be hard to know or remember how it should be inputted in a single text field. For these cases, it may make sense to have a more explicit form with separate fields for the different inputs. A down arrow in the search bar will drop down a search form with explicit fields. Below we see the bar before and after the search form has been dropped.

calendar.png
seacrh_form_start.png

What would you like to do?

When the search form is dropped down the first thing we need to do, is to choose what we would like to do? Or in other words what we would like to instruct the application to do. When we make our choice the form will show specific input fields for that. The different choices we can make matches the features described in previous posts. They can be seen below together with the specific form fields for each choice.

The first field shown in all forms is a calendar field. This indicates the desired calendar and should actually default to the calendar shown in the search bar (Danish). It doesn’t do so at the moment as I haven’t implemented much logic except the bare minimum to be able to illustrate it here in the blog.

Content area

The main part of the application, all the space below the search bar, is reserved for showing the results of our queries specified in the search bar or search form. I haven’t designed or implemented this part yet, but will discuss it here in preparation for designing it later.

When the calendar application is opened, and no query has been specified, there is nothing obvious to show. The space may be left empty, it may show a calendar of the current year, it may show the last result from last time the user used the application, it may show some help text about using the search bar, or something else. I lean towards showing a help text about using the search bar. This may be beneficial for first time users, but also occasional users.

The different types of results to show in the content area are fairly diverse. One type of result is just a date, another is a calendar of a year, and yet another is a list of named days and when they fall in a year. The application needs to support the varied results, but we can try to align them in some way for both aesthetic as well as usability purposes. Here is a suggestion of grouping information that may be similar for most of the different types of results.

  • What is being shown (i.e. how was the query interpreted)

  • The main result (which will obviously differ)

  • Additional explanation

  • Additional links or related queries

For all results it may be relevant to show a text about what is being shown. This is good for a quick overview, but also to address ambiguity and doubts. If one enters a complex query in the search bar directly it will be good that the application shows how the query was interpreted. If one uses the drop down search form then the explicit fields should remove ambiguity, but still the search form disappears to show the result. The query may be formulated in the search bar afterwards, but again there it may be compact and in some cases perhaps be difficult to interpret.

For several of the types of results, it may make sense to give some explanation or extra information to understand the result. For a year calendar and the list of named days for a year, we may indicate noteworthy details. For the Danish calendar this could be whether it was following the Julian (old style) or Gregorian (new style) calendar, whether it was a leap year and so on. For a date calculation, it could detail the sub calculations, i.e. in what order the years, months and days were subtracted or added to the specified date to arrive at the result.

The additional links for a year calendar could just be to browse the previous or next year. For a date calculation it could be links to show the calendar of the years involved, so one can manually inspect if the result is correct. Similar for a converted date a link could be provided to the result date in a year calendar.

Until next time…

Next week I’m going to visit my wife in Greenland. She has been working in Qaqortoq as a temp for a month and we will do a small trip north along the west coast before heading back to Denmark together. I’m unsure how much time I will take away from the trip and also uncertain if or what type of internet connection I will have. I hope to be able to post something next weekend, but if not, I expect to give an update the weekend after. I’ll be working on designing the content area described above.