Who said anything about designing wikis to behave like web sites? A stereotypical blog with entries ordered and always in the same order, that I like. Every blog entry stays in the same place respective to other entries. Things haven't moved on me. So there is cognitive stability. Things are where I expect them to be. Story river can get cognitively unstable pretty quickly, easy to get lost.
Sure, the story river is very useful to those who know the story river (are used to it), but a bit more challenging for those who are used to a stable-looking stereotypical blog, but not so much used to the dynamism of a story river. Easy to get lost after a while. Well, understanding that not all folk cognitively process the same way. I'm sure some folk are immediately at home with the story river. On Tuesday, July 27, 2021 at 7:34:42 PM UTC-3 TW Tones wrote: > All, > > I treasure the story river, once I install some support tools, for > projects, todo and creative writing. I understand that designing a wiki to > behave more like all other websites is desirable in other cases. > > What attempt's I have made to look like "normal websites" has worked fine. > Perhaps a few layouts and tools that help designers create such standard > sites would help. > > Here is an unfinished blog site design of mine > https://anthonymuscio.github.io/TWBlog.html, keep in mind that the > infinite scroll similar to the story is a common design approach for blogs > or news pages. > > Also there is a setting to update the address bar that makes forward and > back work as long as the load times are not too high. See ControlPanel > > Settings > Navigation Address Bar > <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FControlPanel%2FSettings%2FNavigationAddressBar> > > Regards > Tones > On Tuesday, 27 July 2021 at 23:36:52 UTC+10 ludwa6 wrote: > >> On Tuesday, July 27, 2021 at 1:55:52 PM UTC+1 [email protected] wrote: >> >>> I pretty much always see browser back and forward buttons as evil. >> >> >> BLASPHEMY! Ted Nelson is rolling over in his grave right now, @Charlie; >> you'd better recant, or face hellfire & damnation yourself :-) >> Seriously tho: Lot's of people rely on those browser built-ins (not to >> mention me) -besides which: to whatever extent there be anything like a >> standard feature in ALL browsers, those arrow buttons are two of the few, >> so... This is not an issue to blow off, if we're talking here about >> mainstream pedestrian usage of TW as a worthy goal. /w >> >> I'm also no fan of the storyriver in TiddlyWiki. >>> >> >> Here i have to agree: Story River *as implemented by TW* (not the only >> implementation around, NB) is a foreign concept to most inveterate web >> users -which does bring some interesting possibilities, don't get me wrong, >> but still: anything that so stretches the visual language of story-telling >> on the web has got a serious usability obstacle to overcome. /w >> >> >>> ..For whatever reason, staying within the boundaries of one "display >>> all" tiddler works best for me: >>> >> >>> - either display content in that tiddler based on selections in a >>> sidebar menu (I'm on the fence about that approach) >>> - Like I've done with my Favourite Stuff and Projects >>> >>> <https://intertwingularityslicendice.neocities.org/CJ_ProductReviews.html> >>> TiddlyWiki >>> - or have everything displaying (or available from) that tiddler, >>> making use of details widgets (or other widgets) to hide/show content, >>> and >>> making use of modals for displaying extra content >>> - Like I've done with my online resume >>> <https://cjveniot.neocities.org/> TiddlyWiki >>> >>> Those are two clever workarounds you've developed, Charlie, for those >> who (like us two at least) find the river-of-tiddlers approach to nesting >> information kinda awkward. >> Your menu-of-radio-buttons approach is much more familiar and therefore >> usable for most, i would say... >> And those click-to-reveal-content arrows (sliders?) are something of a >> standard in the world of outlining afficionados, and also quite a popular >> UI feature on the web. >> If there be any way to turn these two models of yours into a sort of >> "skin" that could be easily overlaid on an existing TW instance, that would >> be awesome! /w >> >>> >>> - >>> - I figure my preferences, always a work in progress, would be >>> far from universally appealing. Brains are so wonderfully diverse, >>> I'm not >>> quite sure what could be universally appealing. >>> >>> Agree: no point trying to be all things to all people -although, in the >> world of TW geeks, you could almost make that claim. >> Am just saying: if any of you TW devs ever hope to engage something like >> a mainstream audience w/ your app, you've got some serious usability issues >> to overcome... >> And if you somehow manage to pull that off, please share your solution >> here, for goodness sake! >> >> /walt >> >> >> >>> On Tuesday, July 27, 2021 at 8:59:36 AM UTC-3 ludwa6 wrote: >>> >>>> Based on my own experience of trying to engage non-technical users >>>> -i.e. those on whom the power & flexibility of TW is not only lost; it is >>>> actually experienced as frictional- i must say: this issue goes so deep, i >>>> don't know how we might solve it, if indeed we can. >>>> >>>> More specifically: two issues i've noted as so frustrating to such >>>> "pedestrian" users, they give up before even trying to understand are: >>>> >>>> 1. Native navigation features in the browser are essentially broken >>>> by TW, in that i can't use forward and back arrows to move off the page >>>> and >>>> come back to the place where i left off; and >>>> 2. To whatever extent i do any editing of a TW instance that i then >>>> want to save, i wind up with the totally unexpected result of a new >>>> multi-mb file on my desktop, and no change in the online instance i >>>> thought >>>> i was updating. >>>> >>>> If there be any good way of overcoming these obstacles -beyond simply >>>> instructing the user in context to forget about both (1) their browser's >>>> navigation controls and (2) making changes to the online instance- i've >>>> yet >>>> to see any example of it. If in fact any such prior art exists, it would >>>> be great if someone could share it here! >>>> >>>> /walt >>>> >>>> >>>> On Tuesday, July 27, 2021 at 11:45:06 AM UTC+1 TiddlyTweeter wrote: >>>> >>>>> TW Tones wrote: >>>>> >>>>>> ... I do think a primary use of tiddlywiki is for private bespoke >>>>>> "free wikis" and unpublished tiddlywiki's which evolve to a users needs, >>>>>> thus perhaps they never mature to a finished product. That is there may >>>>>> be >>>>>> many more times the number of "free" wikis than those suitable to be >>>>>> published. >>>>>> >>>>> >>>>> I guess that is right! Actually, further than that, it is indicatively >>>>> good of serious usage by folk who can feel good wetting their whistles >>>>> on >>>>> code and relish perennial openness, revision and evolutions. All to the >>>>> good. >>>>> >>>>> Yet, I was kinda suggesting there is, I think, likely a large range of >>>>> audience types, somewhat different, who thrive best on complete apps. >>>>> Who they are and how many there I don't think we know at the moment. >>>>> >>>>> I think it is an interesting issue. In brief, my question kinda edges >>>>> towards: What happens, making apps that only document a de-limited range >>>>> functions to better MATCH common (delimited) need spaces tightly? >>>>> >>>>> That is why I flagged the thread "Avenues." It kinda captures that >>>>> idea. >>>>> >>>>> Best wishes >>>>> TT >>>>> >>>> -- 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/19ba90ac-8649-4d85-9ba8-25c6a27697d0n%40googlegroups.com.
