All of those examples boil down to very simple forms, web 1.0 style forms. CRUD.

Fill out an email form, hit submit. Fill out my tax form, hit submit. Fill out a ticket form, hit submit. It's prettied up CRUD, but it's CRUD.

There's no high levels of interactivity, nor any sort of need for client side state in any of them.

▲

ndriscoll 4 days ago | parent | next [-]

The tax one is especially funny: those "applications" just walk through the same information you'd write on the paper forms! I do free filing every year and "paper forms on the screen with a 'calculate' button for some fields" is the literal UI.

▲

ozim 4 days ago | parent | prev [-]

Wow I see you never had to edit more than 20 things on a list in a Web 1.0 submit form style.

Like go over 20 jira tickets to update the names or adjust different properties on different ticket.

▲

mdavidn 4 days ago | parent | next [-]

Jira itself does bulk editing with traditional web forms. I'm thinking of that "wizard" flow: The bulk edit operation itself is the "HTTP resource" the user builds up and submits.

	▲	ozim 4 days ago \| parent [-]
		Bulk editing yes. Now read again "different properties on different issues". Like you are not going to bulk edit task requirements or set title for 20 tasks to the same thing.

▲

timw4mail 4 days ago | parent | prev | next [-]

Jira is a horrible tool I only use because I am forced to.

▲

skydhash 4 days ago | parent | prev [-]

The old way was ctrl-clicking to open the form in a new tab/windows. And when AJAX, it was easy to use jQuery to make update request.