You just need to rethink the form, which is also an inheritance from print media, as a possibly fuzzy dialogue. Incorporating multimodal input, extracting information from uploads, etc., is a huge accessibility win. This is totally achievable right now, it’s just a matter of viewing the "form" as an interaction designed to fulfill a predetermined goal. What actually complicates forms is handling conditions, state tracking, and synchronization, which can become arbitrarily complex. This sort of dynamic behavior can never be fully standardized. So special cases are always going to need special solutions.
> Hierarchical tree, Categories, tags and search.
I think it's important to highlight the distinction between exploration and retrieval. Tags and categories are perfect for powering indices and lists, enabling opinionated exploration interfaces. However, when it comes to open-ended retrieval, arbitrary conventions don't really help. Retrieval requires the searcher to have some prior information on patterns, which are media dependent.
To make the retrieval problem more manageable, information needs to be structured in a predictable manner. Patterns are powerful tools for enabling and enforcing memorization. For example, if I want to retrieve a specific academic paper, my search model will align with the typical information pattern of academic papers. This pattern encourages me to memorize key metadata, such as the publication year, author names, institutional affiliations, and keywords in the title. These elements form the standard metadata body for this type of content.
I've never actually used it but for laughs I one time elm.setAttribute('value', elm.value) for each field so that the values are in the html, then just upload the form innerHTML, append it to a file and use some dom/xml parser to get at the values. If the user needs to edit the values simply reinsert the html form into a page. If they only need to look at it use ccs to disable pointer events and remove the outlines from form fields. It was a pretty hilarious experiment. The form all of a sudden worked just like the paper version. You write your name on the dotted line where it says name then the data is stored right there.
With some js I could easily add field sets and sub sets. For example click add address, add house numbers, add additional employee/function/phone numbers sets, they can each have 100 email addresses and 1000 websites etc
xpath isn't sql but if the data looks this much like xml?
Converting posted values into table rows and back makes me feel like I'm doing something I'm not supposed to. Tables do not fit our mental model. What is the right solution if you only have one customer who has 6 phone numbers? The enterprise thing to do is add a table with phone numbers and give each number a number. lol?
DB performance is of course godly at scale but if it is just one form that lives on the users computer.... it might not be a nail?
> Hierarchical tree, Categories, tags and search.
It's a fun puzzle, no idea how far we are solving it. We should probably record what one looks at and have a button to mirror a publication locally.
I've often pondered how discovery can be pushed so that things of interest to you may gravitate towards you (and to those with similar interests). 100% accuracy at that would be a game changer. Someone out there is writing precisely that what I need or want to be reading.
You just need to rethink the form, which is also an inheritance from print media, as a possibly fuzzy dialogue. Incorporating multimodal input, extracting information from uploads, etc., is a huge accessibility win. This is totally achievable right now, it’s just a matter of viewing the "form" as an interaction designed to fulfill a predetermined goal. What actually complicates forms is handling conditions, state tracking, and synchronization, which can become arbitrarily complex. This sort of dynamic behavior can never be fully standardized. So special cases are always going to need special solutions.
> Hierarchical tree, Categories, tags and search.
I think it's important to highlight the distinction between exploration and retrieval. Tags and categories are perfect for powering indices and lists, enabling opinionated exploration interfaces. However, when it comes to open-ended retrieval, arbitrary conventions don't really help. Retrieval requires the searcher to have some prior information on patterns, which are media dependent.
To make the retrieval problem more manageable, information needs to be structured in a predictable manner. Patterns are powerful tools for enabling and enforcing memorization. For example, if I want to retrieve a specific academic paper, my search model will align with the typical information pattern of academic papers. This pattern encourages me to memorize key metadata, such as the publication year, author names, institutional affiliations, and keywords in the title. These elements form the standard metadata body for this type of content.