Yeah wizards have a bad reputation, perhaps the good old auto complete mechanic could be retained, but with better options and info

Relevant to this discussion might be Smalltalk's find-by-example and Haskell's Hoogle (search by type).

good point, I think 90% of the time the examples are the most useful part of the docs

set-size(my_set), where set-size is implemented by dynamic dispatch on its argument.

This also reminds me of the idea of records as (dependently typed) functions from a key type to whatever thing the struct was constructed with (or updated with? Hmm).

I'm reminded of Barry Jay's Pattern Calculus. If on the one hand a hash table is a bunch of key, value pairs and, on the other, a standard lambda takes anything and uses it to come up with something else, you can imagine a pattern as living somewhere between: takes some things and uses them to come up with a value. Given two patterns you can glue them together. The standard way is that if the first one matches you take it, otherwise check the second one.

Not sure what he's been up to in the last while https://scholar.google.com/citations?hl=en&user=eWreFm4AAAAJ&view_op=list_works&sortby=pubdate.

@William Taysom I looked into Barry Jay’s stuff a while ago and remember not being impressed. Is there something that patterns are better than functions at expressing? One can already compose functions in many different ways.

Well, not at all in an important sense, but kind of depending on your domain. Patterns here basically amount to partial functions. So if your domain happens to be all about partial functions (that's me sometimes where I end up using a lot of tables), then there's something to find here. But it's not going to be anything more than having a few functions for nicely composing a -> Maybe b, generally.

I guess a potential important difference can be whether you want to model order. For instance, Rubyist that I am, the keys in a Hash are ordered and I use this all the time. In another context, you may not want to keep that information around.

Another thought that I had while trying to remember the pattern calculus is why prefer a composition operator like this

<+> :: (a -> Maybe b) -> (a -> Maybe b) -> (a -> Maybe b)

(f <+> g) x = f x `orElse` g x

over something that collects all the results:

<*> :: (a -> [b]) -> (a -> [b]) -> (a -> [b])

(f <*> g) x = f x ++ g x

And so on.

I think Jay's most interesting idea was in giving up referential transparency for a kind reflection. I like being able to look inside my methods. So that's neat.

@William Taysom Partial functions are my mortal enemy 😇. It’s a strict requirement that my programming language only permits total functions. The challenge is then making it expressive enough that you never feel you “need” a partial function somewhere!

Thanks for the details though. Sounds like pattern calculus is not what I want.

The UI just renders what is in the database. Queries can make use of all the functionalities supported by SQLite.

Tasks listen to UI events, system events or database events.

In the example above, there is a task that listen to changes to the todos and automatically uploads to the server.

This seems to eliminate the need for boilerplate or unnecessary architecture components. I have built a production app with this and the speed of iteration was really cool.

I'm just curious if there are some fundamental issues with this that I'm missing.

this approach is similar to one of eve’s pro types, although they were closer to datalog than sql. you might find their experience report useful: https://youtu.be/WT2CMS0MxJ0

Thanks Garth. I will check the video out.

Main challenge I think of is the scenario where an temporary edit state doesn't validate. As an abstraction, suppose you have two text fields which should contain non-negative integers that sum to 10. Honestly, I think the solution is to keep both keep both committed consistent values as well as temporary being edited values in the database. Then the UI has less to do with it, and it's more a question of when/how to commit changes.

I have developed a similar dsl + framework like this. The main challenge is dealing with async. Network data fetch is inherently async, but user expect the UI to be sync. Binding async state to UI is a open challenge still being addressed by UI framework like React. While render-as-you-fetch (https://reactjs.org/docs/concurrent-mode-suspense.html) looks promising, but React did not ship with concurrent mode yet for many good reasons. Another challenge is efficient data caching & batching. With manual I/O, developer is manually tweaking the I/O operations. Binding async expression to UI, force the developer to rely on the framework to do the right thing. It is possible to auto-optimize in many cases, but it will require the developers to "let go" some control. It requires significant trust between you and the developers using your stuff to write software.

looks like flutter, I like it

Thanks @taowen. Did you open-source the framework you built?

We are working on doing these auto-optimizations. So far, we have seem some impressive results. But getting developer trust is indeed a salient issue.

@William Taysom valid point. That solution should work. Another solution (for the example you gave) will be to have a predicate on the insert trigger, so you can leave the temp state in the widgets themselves.

Thanks so much for the link 🙏 Garth Goldwater

This thread was partly triggered by Emmanuel Oga's recent thread on autocompletion wizards (https://futureofcoding.slack.com/archives/C5T9GPWFL/p1607263213204500). Autocompletion is typically a mode, but so lightweight we don't think of it as such. Turning it into a wizard definitely makes it much more obviously modal. Just something to think about.

the obvious huge counterpoint to "modes are bad" is vim, where everything is about modes. From the top of my head, it seems modes can be a great asset for the "advanced user" but could take a bit longer to get used to. Modes are so useful that even a lot of emacs users use them (evil mode). I have never related modal editing in vim to modal dialogs though, I guess there are points of contact but the experience seems pretty different.

one way i have been thinking about it is "the least restrictive UIs provide the highest possible branching factor from current state to next action"

vim's command mode lets you do an incredible number of things very quickly after entering it, so while modal, it isn't super restrictive in terms of the order you have to trigger it in, or the facilities it exposes once in it. if vim had 4000 modes, each for each little operation, it'd be different because the user would have to spend a lot more time trying to figure out which mode to use

modal dialogs in UIs and especially wizards I think fall prey to that same issue, the user has to spend time figuring out how to trigger the right UI state to do the thing they actually want to do. "i know this button is somewhere but i have to figure out how to bring it up to press it" happens with modals sometimes

i think autocompletes are an interesting pattern too because they aren't completely modal, they only change what some of the interactions you could take do, not all of them. you could keep typing characters along your merry way and dismiss the autocomplete. In that sense you never experienced the other mode, it's only if you press an arrow key or enter or escape that you have ... experienced ... the mode. I think with those keys in particular we're super accustomed to their behaviour changing in different contexts so the friction may not be as obvious or painful as the kind Larry hated

so i agree with the idea that time-in-strange-modes being short is better, but maybe an added quality would be different modes should overlap as much as possible

Emmanuel Oga I actually had a few notes about Vim that I dropped on the editing floor 🙂 A few ways to work within a modal interface:

• Make it obvious what mode is active.

• Perfect undo/redo everywhere.

• Add all the things to history. In Vim for example, you can start typing a command at the : prompt, change your mind, hit Esc and go back to other things, hit : and hit up-arrow -- and find the command you typed in but never ran.

You're right that modal dialogs aren't exactly the same thing as Vim's modes. I'd actually not connected the two until Bret Victor mentioned Vim above. It might have been some creative license, since Larry Tesler's work seems to mostly predate Bill Joy's creation of vi. So Harry Brundage's over-arching framework of "how restrictive is your UI?" seems useful.

Harry Brundage While you're right that I don't usually think of autocomplete as a mode, I have little skirmishes with autocomplete in various apps on a near-daily basis, where the app gets in my way and I have to backspace out of what it 'helpfully' completed. So it does seem useful to think of it as a modal interface, because the errors happen when I'm not conscious of what mode I've suddenly gotten put into. Particularly in combination with overly sensitive multi-touch or palms accidentally touching the trackpad, patterns that have sadly gotten all too common. To me, "never autocomplete" feels like a useful corollary to "don't mode me in" that also overlaps with Christopher Alexander's principles of giving UIs a sense of stability.

I was nodding along when you said, minimize restrictions. However, I think Vim has way too many modes: https://en.wikibooks.org/wiki/Learning_the_vi_Editor/Vim/Modes

because the errors happen when I'm not conscious of what mode I've suddenly gotten put intoDoes that happen to you in traditional code editors? I totally know what you mean and I think you're right, if the implementation is actually interjecting content into the medium without you asking it to that's violating direct manipulation and surprising / uncomfortable. I haven't experienced that with code editors though, usually it shows a ghost or what have you until you confirm or select a different suggestion, which I like

However, I think Vim has way too many modesI agree, I never invested enough time in learning all of them or find a need for the strange ones often enough to stay practiced in using them effectively

i am mostly just parroting principles from https://www.wiley.com/en-us/About+Face%3A+The+Essentials+of+Interaction+Design%2C+4th+Edition-p-9781118766576 too, they go into a lot of depth on modes and the difference between designing for beginners vs intermediates vs experts and what considerations apply when

Does that happen to you in traditional code editors? I totally know what you mean and I think you're right, if the implementation is actually interjecting content into the medium without you asking it to that's violating direct manipulation and surprising / uncomfortable.

Totally. I never experience this with Vim anymore, because while there are lots of modes the transitions are well-defined and the rules don't keep changing over time. So while I take seriously when people say it's hard to learn, yeah, it doesn't affect me.

Stable opt-in transitions does feel like a good principle to add to the list.

Let them flounder about in their "normal mode." Normal isn't good enough for me! I want exceptional, IDEAL, I want… glorious mode, that's what I want.https://emacsconf.org/2020/talks/07/

I honestly did not fully get the proposal but I think is related to your question. It seems to describe a way to "stack modes" such that modal editing can be more regular and require less time to learn.

The best treatment of modes that I can recommend in book form is https://en.wikipedia.org/wiki/The_Humane_Interface. Tesler's "NOMODES" was one of those cases where one makes the mantra a target toward which to strive, even if it is beyond achieving completely.

No ebook, but I found http://nitpicker.pbworks.com/w/page/12451253/The%20Humane%20Interface

Raskin may have been biased by his choice of computers:

sorry, couldn't help it 😛

(from https://en.wikipedia.org/wiki/Jef_Raskin)

From what I recall of The Humane Interface, "modes" are defined such that they only count when the user's main attention is on something other than the fact that program is in a "mode". Vim's modes count because the user is looking at and thinking about the text. I'm not sure "modal" dialogs count, since it's pretty hard to be confused about whether your actions will be interpreted by the dialog or not (which is not to say I fully endorse their use; IMO they tend to be clumsy).

Kartik Agaram> "You're right that modal dialogs aren't exactly the same thing as Vim's modes. I'd actually not connected the two until Bret Victor mentioned Vim above. It might have been some creative license, since Larry Tesler's work seems to mostly predate Bill Joy's creation of vi."Bill Joy didn't invent modal editors. Tesler didn't like the modes in the Bravo editor at Xerox, so he invented the Gypsy editor, which was modeless.

https://en.wikipedia.org/wiki/Bravo_(software)#EDIT_command

Modes in the broad sense are unavoidable so we have to figure out how to wrangle them. Even in non-modal text editors, if I open the File menu I'm now in a 'mini mode' where I can't just type what I want. If I open a command palette, that's another mini mode. Dialog boxes are no different.

Ted Nelson observed in one of his talks something to the effect of "applications are the ultimate mode" - talking about how each application is a mode in itself. The Photoshop mode on my computer works very different from the gmail mode, etc.

The best demodifying I've seen is in the Civilization series of games. At the start of your turn, a bunch of things request your attention, "Okay, boss, what do I do now?"

Originally, it was one modal dialog after another. A decision might require looking at the state of the map — unavailable since the mode had hijacked the UI. Late in the game at dozens of modal windows would show up before you could check, so you might adopt the strategy of making a silly choice as a signifier that you need to come back to it.

In the latest Civ games (can't recall when exactly), instead of the modal hijack, you get a to-do list at the start of every turn. When you're good and ready you can pick an item, and if after looking you decide you weren't as good and ready as you thought, you can escape and look around more.

Even when relatively small, modal forms can get in the way of you seeing what you need in order to fill the form. Consider find and replace. Sometimes you may think, "I want to do a find and replace action." You bring up the window/panel/tab, and it turn out the next thing you actually need to do is go hunt for the precise thing that you want to find.

"Applications are the ultimate mode": very true, and aptly explains why Raskin didn't really like applications. :D

The debate about modes has been going on for decades, but I have never managed to take sides. There are good and bad user interfaces (judging by experience) in both the modal and non-modal camps. Perhaps modes as such are not the fundamental criterion? Perhaps they are just the visible symptom of something else?

Kartik Agaram i think the autocomplete example falls into Raskin's category of "quasimodes" (hat tip Mr Rusher) , which are modes that a user knows that they are for sure in

Raskin advocates either getting rid of [modes] entirely or using "> https://en.wikipedia.org/wiki/Mode_(user_interface)#Quasimodes> " (a term he invented in the book); a quasimode is a state in which the user must make some constant physical action in order to keep the computer in that state, so that they cannot forget that they are in that mode; an example is the keyboard's > https://en.wikipedia.org/wiki/Shift_key> .i think that the panel that pops up right below your cursor is a pretty darn obvious indicator that you've entered a different mode

Harry Brundage Raskin was a bit more extreme than that. There were a pair of buttons on the https://en.wikipedia.org/wiki/Canon_Cat called "Leap keys" that one could hold down while typing to incrementally search (one for forward, one for backward!). The idea was that you would develop an internalized physical pattern -- muscle memory, basically -- for this action that would result in increased fluidity with the interface.

that's awesome, i bet Raskin would have been a great organ player, sheesh

(because of all the foot pedals)

I'm slightly confused about what "modes" means in modern GUIs. The story about Tesler I always thought was about global modes in applications at the time, more towards the vim kind.

To me it seems concepts like progressive disclosure and context sensitivity have replaced the need for global modes in complex modern GUIs, and the discussion of how these are somehow still related to modes seems somewhat moot to me, as I don't think they have much to with it…?

For instance, I'm having a hard time understanding how an auto-completion overlay menu is related to modes. Am I missing something?

Probably not. This thread is showing me that I was conflating there.

there's still some pretty modal modern GUIs if you ask me, like the tools palettes in Photoshop or AutoCAD or what have you. You have the cropping tool/mode, the brush tool/mode, the redeye correction tool/mode etc

there is a pretty sweet video about leap / cat on YT, if anyone is in quasi-modeless mood: https://www.youtube.com/watch?v=o_TlE_U_X3c

Kartik Agaram The Humane Interface book is available at http://archive.org.

I just read recently about the history of the autocomplete feature in the iPhone in http://creativeselection.io. Turns out that autocorrect helps with a hardware constraint: keys in the original iPhone touch keyboard were too small for typing without making errors.

Was religion in a more enlightened form before print culture?

It’s complicated, but kind of, because religion is primarily about explaining the spiritual. Religion sometimes explains the material (though most frequently when the material is inexplicable), like the creation of the Earth, and stuff. It also occasionally focuses on the logical…

But religion is primarily there to explain that which is immaterial — the connection between this and that. The connection between your soul and your body, between a mother and a child, between our past self and our future self, between love and creation, etc.

Most of what religion tries to discuss can’t be easily reasoned about, or represented symbolically. It is mostly felt or experienced. Hence, religion can’t be put into print. Sure, stories can, traditions can, beliefs can. But the stories, traditions, and beliefs aren’t the religion. They’re merely pointers, trying to reference different aspects of the religion, which is not itself something that can be put into words.

As an increasing amount of our thought was offloaded from feelings to textual analysis, we started thinking like readers. And readers think in a different way from non-readers. Just like speakers think in a different way from non-speakers (see https://en.wikipedia.org/wiki/Monastic_silence)

In many ways, the argument is that the rise of print led to a subtle mind-virus: “If I can’t read about it, it doesn’t exist.”

But not everything can be read about.

Reminds me of the rise of writing: https://fs.blog/2013/02/an-old-argument-against-writing

Ideally a document author would reify some DAG of topics to support any other one.

https://en.wikipedia.org/wiki/Directed_acyclic_graph#Construction_from_cyclic_graphs

(the smallest such set is https://en.wikipedia.org/wiki/NP-hard to find)

when something is NP-hard to find, you know it is valuable 🙂

http://learnawesome.org I think they are building something you are looking for.

Though it is community driven and opensource, so not sure of the quality of links.

(one PR I did, that's my association with it)

Finding good resources is a even harder problem, most websites if left alone get filled with spam anyways.

I think you're blaming the wrong level of abstraction. Links are a mechanism, and writing linear prose is a mechanism. Teaching by non-interactive writing alone is hard no matter what mechanisms you use. Nothing will ever make it easy to bridge the gap between minds, transmit a complex model from one mind to another.

Nyxt (https://nyxt.atlas.engineer/) explicitly stores your browsing history as a tree. Hacking in some more metadata is probably pretty simple, and then some tooling on top for querying it

nyxt is a great find! thank you for sharing

I think I get what you mean Kartik, that suboptimal knowledge transmission is not necessarily a problem of the medium (Hypertext).

My point specifically about hypertext though is that authors of specific materials could point readers to specific parts of a "trail" to help them cut to the chase.

An author could draw a map spanning more than a single "hop" to the next document.

Things like nyxt can help me keep track of my own steps, which is pretty cool.

There are some standards for more powerful links that never got traction(xpointer/xlink).

There's also https://web.hypothes.is/ (web annotation). This last one could work for what I'm talking about since annotations are based on RDF, arbitrary arrows can be drawn in any direction.

I've always found semantic-web mechanisms to be concerned with 0.001% use cases nobody will ever care about. But perhaps people in glass houses trying to make device drivers easy to understand shouldn't throw stones.

oh snap

😛

I get all the hate semantic web stuff gets... it seems like nothing ever gets completed and polished before they move to the next moonshot. Current one is https://solidproject.org/.

http://diveinto.html5doctor.com/past.html#postscript, although biased, was pretty for educating myself on the workings, successes and failures of the W3C.

"The ones that win are the ones that ship."

I feel like saying I am a non-techie in this space is like admitting to be a sheep in a den full of lions. Knowing that the lions here are pretty nice, I will bare my neck and admit I'm still very early in my tech-evolution. I'm more of a product manager than a coder.

What's up?

Hi Tim, no lions here! We're all nice now - especially since the Great Purge of Dissidents and Grumpies!

I was hoping to find some FoC-aware non techies to run my ideas past. You probably guessed it was more about you potentially helping me than the other way around! But on the plus side, you may like the ideas and it may change your life forever...

Computational scientist here. Not sure if that makes me a techie. I see myself as a power user rather than as a developer.

Yes please! I love being a thought guinea pig! I'm so relieved to hear about the great purge.

Konrad: hmmm.. you sound slightly techie! 😄

Tim: yeah, it was bloody, but the right thing to do!

I would love to help sketching some designs. Where I normally start is having examples for longer/more complex functions and from there sketch different UX design options

What to do about line getting too long?Just infiniscroll to the right within in a window/frame (perhaps I'm misunderstanding the issue, this seems completely analogous to new lines in a source file).

What about awkward values on the stackI think you'll have to just put a marker on the timeline stacks (like [$1]), then on the left of the screen show [$1]["http://example.com/blah/122512"] with the same colouring. The values are const (IIUC), so you can show a single list of values across all stacks in the timeline view

Your point about BV skimming over the crux of live editing is a whole other thing...

i’m also free to sketch whenever! my initial suspicion on the stack depth stuff is that the stack shouldn’t ever really get too deep—some examples would help here. i tend to err on the side of “worry about it when it’s a problem because then you’ll have enough information to make the tradeoff”

truncation is tricky and my temptation would be to truncate with a reasonable default but make the default accessible. visual stuff like this also benefits from examples. if i were to put my rebol hat on my suspicion would be that long data is often secretly structured in one of two ways: you’re using data to represent a lot of small differences, like with hash ids, and all you need is displaying something like a scannable difference, or it’s deeply structured and made linearized (like urls) and you actually want a struct and to display relevant differences based on some context (in a web app you might care if something belongs to a person or a team, or you might just be interested in document ids)

if you’re just worried about unix compatibility, it might be helpful to investigate the goals: do you want to keep the ui the same? or do you want to have code for unix work on your platform? or do you just want equivalent functionality?

Oh sorry!

😄