AbstractIntroductionOverview of Pattern and WidgetComparison to Other Patterns and WidgetsChallenges to ImplementationOther UsesRelated workCONCLUSIONReferencesTHE FOLK DATE PATTERNJustin Seliger and Degory ValentineBrigham Young UniversityRelevant topics: human-computer interfaces, date authoritiesABSTRACTGathering dates and date ranges from genealogical records can be difficult, especially when trying to preserve the context in which the date is found in the record. Specialized formats and varying degrees of precision complicate date entry and searching. This presentation will introduce a new pattern for handling dates that aims at unifying people’s interaction with date and time entry while preserving the context of the record.INTRODUCTIONCurrent patterns for abstracting dates in digitized records transform the user’s intention into a precise date by constraining the input (e.g. popup calendars) or by constraining the precision (e.g. only accepting a year). However, our genealogical records contain dates expressed in a variety of unconstrained ways. Once these dates have been transformed, any information contained in how the date was expressed is lost. This presentation introduces a new pattern for handling dates so the original expression of the date is preserved. It also describes a possible method of handling user interaction with the pattern, a comparison to common date patterns in use today, and some discussion of obvious challenges to implementing this pattern.For convenience of this presentation, the SQL term “datetime” represents a date with high precision in a sortable format such as “1900-01-01 00:00:00”, although the actual storage method and format is irrelevant to this presentation. The term “widget” refers to something users interact with to input data that is not coupled with the storage, e.g. popup calendars, slide bars, or radio buttons.OVERVIEW OF PATTERN AND WIDGETThe primary idea of the pattern is to store the raw user input along with the datetimes they represent. Every time the date is displayed, the raw input is used. Essentially, the widget will be interpreting two sets of dates, one that users read and use and a corresponding value that the computer understands. Every time the date needs to be searched or sorted, the datetimes are used. Users never need to worry about datetimes, and the script never needsto worry about the folksy way users describe dates (the “folk dates”).Since people describe dates with varying levels of precision, each folk date should be parsed into two datetimes. Additionally, people specify dates with varying formats for different reasons. Folk dates may include local or period-specific formats. This is where the expression of the date becomes especially meaningful. The following two tablesshow folk-date-to-datetime conversions. Table 1 contains examples of simple folk dates that only reference a date or date range. Table 2 shows more expressive examples.Folk Date Starting Datetime Ending Datetimethroughout January 2011-01-01 00:00:00 2011-01-31 23:59:598 Aug to 12 Aug 2008 2008-08-08 00:00:00 2008-08-12 23:59:59August through October 2010-08-01 00:00:00 2010-10-31 23:59:598 Aug 08 8:30pm 2008-08-08 08:30:00 2008-08-08 08:30:59Table 1: simple folk datesFolk Date Starting Datetime Ending DatetimeChristmas 2009 2009-12-25 00:00:00 2009-12-25 23:59:592 Richard III 1484-01-01 00:00:00 1484-12-11 23:59:591732 – c. 1799 1732-01-01 00:00:00 1799-12-31 23:59:59Summer of 69 1969-06-01 00:00:00 1969-08-31 23:59:59Table 2: expressive folk datesThe primary idea of the widget is to allow users to express the date without constraints. Datetimes should be parsed from the unconstrained input. The most available technology in which this can be implemented is the basic HTML text-input element (<input type=“text” />), so this presentation will describe the widget from that platform. A user types the date as they wish it to appear. As they type, their input is sent asynchronously by JavaScript to a web service that parses the input and returns applicable datetimes. The parsed datetimes are displayed to the user so they can understand how their date is interpreted. If the parsed dates are incorrect or the input cannot be recognized, the user should be able to manually specify start and end dates. The widget might look like Figure 1. In Figure 1.1 the user begins typing a date range. Since only a single day is parsed, the widget displays the same date twice (starting and ending on August 8th). In Figure 1.2 the user has completed typing the date range and both the starting and ending dates are recognized by the widget. In Figure 1.3 the user interacts with the starting date to demonstrate that the dates can be manually adjusted (possibly using some more conventional widget). Figure 1.1: folk date widget with single dateFigure 1.2: folk date widget with date rangeFigure 1.3: users can manually change datetimes as neededCOMPARISON TO OTHER PATTERNS AND WIDGETSThe appearance of the widget as described above doesn’t look very radical, but the actual user interaction and conceptual model is significantly different. Consequently, a comparison to other widgets as a group is meaningful.Advantages:- Text is a familiar and standard input type.- Dates are formatted exactly as the user wants.- Dates can be displayed as they appear in records.- Specialized and localized formats or mixed formats become sortable and searchable.- The widget doesn't restrict user input format.- More information can be captured using expressive date formats.Disadvantages:- Dates may have inconsistent presentations - i.e. "from Jan to Feb" and "between Jan and Feb".- Relative dates will lose context - i.e. "from last Friday to this Friday" when viewed next month.- The widget may confuse first-time users by not restricting the format of their input. They might ask, "How do I need to write the date?"- The widget doesn't offer any assistance to users such as an interactive popup calendar.CHALLENGES TO IMPLEMENTATIONPeople can express dates ambiguously, but computers can only understand dates deterministically. Sometime a date cannot be understood without additional context. For example, middle endian and little endian date forms can't be distinguished between the 1st and the 12th of each month. The date expressed as "6/10/2010" is June 10th in middle endian (America), but October 6th in little endian (Europe). A possible solution to this challenge is toallow