Step 2 in my grand plan for a mini empire of LÖVE ...
# share-your-work
k
Step 2 in my grand plan for a mini empire of LÖVE apps: https://archive.org/details/akkartik-pensieve-2022-07-27 (video; 5 minutes) Not yet released, though. This is just a preview. (Previously: https://futureofcoding.slack.com/archives/CCL5VVBAN/p1656807435038059)
j
Nice! 😊 A couple of suggestions for further exploration: 1. Consider implementing focus-follows-mouse for the individual notes, with input going where you're pointing. 2. Consider placing the command bar full width at the bottom of the app, rather than popping it up on top of the central content. For some reasons why, see this video:

https://www.youtube.com/watch?v=A0TafHXszgM

c
Nice; I like infinite canvas apps. Personally, I think I'd prefer the app to have a 'focus' shortcut instead of a separate app (you could always have a shortcut that launched the app in focus mode for editing a single document). Swapping in and out of focus mode is something I often do.
k
@Chris Maughan By 'focus' do you mean something like a visual mode where only a single 'pane' is visible? I do have plans to maximize a single pane. The capture app is a little more than just that; it's maximizing a new, blank document.
c
I mean like the separate app you did for editing. A shortcut key in the app could make a new blank document, maximized, in the same way.
k
Ah, got it.
@Jack Rusher Thanks a lot for bumping that Philippa talk. It was well worth the rewatch. Summarizing, it sounds like the key ideas for scalable, discoverable UIs are: • one-level menus • off to an edge so they don't obscure people's stuff • that are context sensitive • that show keyboard shortcuts • that expand to something like a ribbon bar when you click on them • that allow searching to filter through their contents This makes a lot of sense. I'll move the palette to the bottom and blend it with the wordstar-like menu I've done before. It's already context-sensitive, though in an ugly, hard-coded way because it's quite a simple tool at the moment and there's only a few context-sensitive exceptions. --- I'm still thinking about focus follows mouse. It's something I've never used before. But I think I see where you're coming from; the current metaphor is already focus follows mouse to some extent since stuff outside the viewport implicitly goes out of focus. Why require an extra click to switch panes within the viewport. Would you prefer focus follows mouse with all panes being editable? Or should I perhaps restrict focus follows mouse to only when a pane is not being edited?
o
nice apps you have created!
j
I like the convention from X where whatever typing you do goes where you're pointing, so yeah — including editing. In that paradigm, clicking is used to position the cursor within the region (window, card, whatever) that the mouse is over. You might not like it! It might be poorly suited to your use case! But also probably worth trying 🙂
k
@Chris Maughan I just added the focus shortcut, and it seems easy enough to maintain so I'm going to keep it. However, I still find the separate app incredibly valuable. It might be that my short-term memory is particularly sensitive. Just seeing something else on screen often causes me to forget what I was going to write (in combination with kids screaming in the background, 3 other things I recently looked at or thought about, etc., etc.) In fact I just ran into a situation where I wanted a blank slate even to query existing data. I go into WhatsApp looking for a travel itinerary my mother sent me, and get distracted by a message from someone else. So maybe I want a (third?!) shortcut that opens on the whole app but without any open files. But then I'm going to end up creating new notes from there, and end up with complex layouts. Then I'm going to have multiple such layouts and need a session abstraction to manage them.. we'll see how far down this rabbit hole I go 🤷🏼‍♂️