Hi Saq, >>> I am now wondering if we should just use the context menu for this. Swipe to show the context menu and have an option to exit editing. I intend to make the menu items that come up in the context menu configurable via a control panel so that it does not get overly crowded and users can customize it to their liking.
My instinct is that this would be quite cumbersome, but it's hard to know without having tried it. >>> I would explore further but I do think it is a very uncommon occurrence when working with Streams to trigger a context menu, and then without choosing a menu item to trigger a different context menu. As such I am not sure that I should dedicate much time to this. The only occasion I can think of where this might happen is if the user accidentally opens the context menu for the wrong node, so yeah it doesn't seem like something worth worrying about. >>> Multiple nodes in edit mode in a single tiddler in the story? How can I recreate that? It should not be possible for more than a single node to be in edit mode in a tiddler. Sorry I wrote that incorrectly. I meant that I will often open multiple tiddlers and find that they each have a node in edit mode, but it is always only one node per tiddler. On Sunday, 10 January 2021 at 14:09:05 UTC [email protected] wrote: > Hi @si, > > Detailed feedback is greatly appreciated, especially when it is well > written and relevant, so thank you for that. > > Before I address some of the specific points you have raised I would like > to clarify that my intention with work on the mobile UX for Streams is to > look for easy and quick gains and make Streams minimally functional on > mobile/touch devices. However, this isn't a priority overall as firstly the > focus of Streams is on a keyboard based workflow and secondly the overall > mobile UX of TiddlyWiki is still rather lacking. > > >> - It feels like I have to hold down a little longer that I would >> expect before the node becomes draggable. I know you wouldn't want it to >> happen too quickly so as not to interfere with scrolling, but to me it >> just >> feels too long. It's hard to say for sure without trying it for a longer >> period, but I think it impacts the UX enough that it would probably >> prevent >> me from bothering to use drag&drop at all on mobile. >> >> This is a browser implementation issue. Streams uses the TiddlyWiki core > support for drag and drop which is based on the HTML drag and drop API. > Frustratingly the implementation is far from consistent across browsers. > Therefore currently drag and drop on touch devices only works on Chrome on > Android and iOS on iPad (but not iPhone). Similarly the delay to trigger > drag handling is dependent on browser implementation. > > The only way to improve this would be to implement custom drag and drop > handling from scratch in TiddlyWiki, which honestly wouldn't be the best > use of the limited resources and time that I have to work on this. > > >> - I have found that whenever I double tap to close edit mode on >> mobile I end up highlighting some text. In most cases this doesn't >> actually >> affect the function, but I do find it mildly stressful. >> >> It is a bit worse than that actually. Some users are accustomed to double > tapping a word to select it, which triggers a double click. Therefore this > is one of the features that I am least sure that it makes sense to keep. > This was something I explored in response to user requests to have a way to > exit editing a node on desktop (and mobile) that did not require using a > keyboard. > > >> - Double tapping to the left of the text to works well, though >> currently I don't instinctively do this. It also feels like it would be >> more natural as a single rather than a double tap. >> >> The issue is that the area to the left is very small when the content of > a node is a single line and can be hard to tap. Furthermore the chances to > accidentally click the bullet and open the tiddler is too high. Due to the > combination of these two factors I am of the opinion that events on the > area to the left of the node are not a reliable trigger. > > I am now wondering if we should just use the context menu for this. Swipe > to show the context menu and have an option to exit editing. I intend to > make the menu items that come up in the context menu configurable via a > control panel so that it does not get overly crowded and users can > customize it to their liking. > > >> - Swiping to open the context menu is super-useful. Currently it >> seems that if a context menu is already open, switching to a context menu >> on a different node requires two steps: tapping to close the menu, then >> swiping to open a new one. I think it would be more natural if swiping on >> a >> separate node did both of these things at once. >> >> One of the goals of the changes in this version was to decrease the > reliance on custom JavaScript and rely on core features. This is more so > possible now as a lot of the tweaks that Streams relied on were introduced > into the core for TW 5.1.23 as they are universally useful. > > The problem in this instance is that the context menu uses the core popup > feature, which needs a click event to dismiss a popup before we can show > another popup. > I would explore further but I do think it is a very uncommon occurrence > when working with Streams to trigger a context menu, and then without > choosing a menu item to trigger a different context menu. As such I am not > sure that I should dedicate much time to this. > > >> - I tried the swipe-to-indent setting and found that it worked well, >> and the lack of visual feedback/ability to undo doesn't strike me as a >> massive problem. However I would probably not use this feature personally >> as I feel that the context menu option is more useful. >> >> I am favouring dropping this for two reasons: > a) with swipe to indent enabled there is no means to trigger the context > menu, which as you say is more useful. > b) while some accidental unindent operations are as simple as a swipe to > undo, others can be almost impossible to undo on mobile depending on the > structure of the node tree. As such I feel any swipe to indent/unindent > feature should show visual feedback that a swipe is occurring and allow the > user to cancel the gesture before it triggers any action. This is of course > doable with a different swipe implementation but it would entail complexity > (and size of code) that I don't think is justified in Streams. > >> >> - One thing that bothered me about the current release is that I >> would occasionally create new nodes from tiddlers that already had titles >> like "tiddler/timestamp" and end up with lots of tiddlers called >> "tiddler/timestamp/timestamp/timestamp" etc. With the new control panel I >> was able to change the title template to my own custom macro that ignores >> any already existing timestamps when generating new titles. I wonder if >> this should be the default behaviour? Here is the macro that I used: >> - \define new-streams-title() >> <$vars timestamp=<<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">> > >> <$list filter="[<stream-root-title>!regexp[^.*/\d{17}$]]"> >> {{{ [<currentTiddler>addsuffix[/]addsuffix<timestamp>] }}} >> </$list> >> <$list filter="[<stream-root-title>regexp[^.*/\d{17}$]]"> >> {{{ [<currentTiddler>splitbefore[/]addsuffix<timestamp>] }}} >> </$list> >> </$vars> >> \end >> >> There is some documentation here on customizing the title format for new > nodes: > https://saqimtiaz.github.io/streams/#Customizing%20node%20titles > > This one is similar to what you have implemented: > > - {{{[<stream-root-title>split[/]limit[1]]}}}/<<now > "[UTC]YYYY0MM0DD0hh0mm0ssXXX">> > > The problem with establishing better defaults is that user feedback is > extremely limited which is particularly frustrating for someone taking a > user centered design perspective. > I would love to hear from other regular users of Streams as to their > preferences for the title format. > > >> - The last point doesn't relate directly to the new features, but I >> might as well mention it here. I frequently find myself opening a tiddler >> and seeing that I have a bunch of nodes left in edit mode, which I have >> to >> toggle one at a time. It would be nice I think to have a way either for >> nodes to be set to read-mode automatically (maybe triggered by opening >> the >> tiddler for a node, or closing the streams tiddler), or an option to just >> set all nodes to read-only in batch. >> >> Multiple nodes in edit mode in a single tiddler in the story? How can I > recreate that? It should not be possible for more than a single node to be > in edit mode in a tiddler. > > Reloading a wiki does reset all nodes back to view mode on node.js as > $:/state tiddlers are not saved. However frustratingly the single file > version of TW does save state tiddlers. I may consider using a $:/temp > tiddler instead. > > Cheers, > Saq > > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/79b86c26-9cef-490d-b08e-c72394bda948n%40googlegroups.com.
