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/0f47f761-59c4-4078-a043-c6a891146f5fn%40googlegroups.com.
