Tiddlywiki5: System images tab proposal (More sidebar tab) - DEMO

[morosanuae]

Hello,
I think this could be a useful addition to the TW toolkit. It's very useful for me. Maybe you will consider it and share your opinion or help me improve it.
My vision is that every aspect of internal structure of TW should be available (at least in a read-only mode) to users for administration purposes.

DEMO:
link

Thanks.

[pmario]

Hi,
Very interesting, thx for sharing!
IMO this is plugin territory.

[morosanuae]

Hi,
I don't want this to be a plugin but a basic feature of the default version of TW. IMO this is mandatory stuff (not necessarily my version) not something optional or exotic. Many basic features/capabilities should be in the default version of TW but they are not (yet). These missing basic features give the app an unfinished/imature look, at least for advanced users.

[TiddlyTweeter]

I think this could be a useful addition to the TW toolkit. It's very useful for me. Maybe you will consider it and share your opinion or help me improve it.

Simple, good. I agree that direct visual accessibility to icons is important.

[tobibeer]

I don't quite see it as a tab in the sidebar and I also think the list variant would be sufficient. Searching is mandatory, imho. Otherwise, scrolling.

I would be in favor of some "components" section in the controlpanel which lists / categorizes some of the more practically reusable tidbits like these images, and possibly even two lines of code / examples each as to how to effectively use them best, should there be helpers around.

[Jermolene]

We already have several places where images are listed:

• the image picker in the edit toolbar
• the page background image picker in theme tweaks in control panel
• the "more/types” sidebar tab

Perhaps the features here could be incorporated into the edit toolbar image picker?

[morosanuae]

Maybe you don't see it (from the coders view) as an important feature but let me tell you that these tiny bits of useful things will add power and quality to the app and not the very complex (and obscure to many) features.

I don't quite see it as a tab in the sidebar and I also think the list variant would be sufficient. Searching is mandatory, imho. Otherwise, scrolling.

@tobibeer the grid view is useful because it puts a large quantity of data right in front of the user (no need much scrolling), just like a gallery. My initial design was to even create buttons that give the possibility to enlarge/shrink the icons in the grid view for a better viewing.

We already have several places where images are listed:

• the image picker in the edit toolbar
• the page background image picker in theme tweaks in control panel
• the "more/types” sidebar tab

@Jermolene, yes but there are not very useful/friendly utilities for the purpose of inserting icons into the content nor to manage them or they don't show the actual icons (types tab). It's a good idea to improve the image picker, like you proposed, but this will cover only part of the problem.
I think we need an utility for managing icons (for an ever growing collection) and even buttons to create/delete them. This will be very useful for beginners or average users at least.
But in the end I'm not a decision factor. If there will not be an interest in this I will close the issue and make a plugin instead.
Thanks.

[pmario]

I did change my mind. ... I think it would be OK in the core!

Since the issue was raised, I personally did need to get an overview of existing images, several times :) and I always needed ot open the "image gallery" in the search bar. ... because I know it's there :)

But new users may be happy with the tab.

[tobibeer]

I think the right spot for this indeed is the editor. Because, let's face it, you search for those images when you want to use them, i.e. add them to some tiddler content.

@morosanuae: you are right, in an editor toolbar, the grid is perhaps more appropriate, although potentially becoming overcrowded in time, so the option to switch views might be nice and possibly only requires some css magic.

There will definitely have to be sections, since core images cannot / should not be deleted permanently (they are shadows anyway). In other words, deleting a core image would only revert it to its corresponding shadow should it have been overwritten by seme "icon theme".

However, icon theming, would not be something you expect a user to do in the editor. That would be something for the control panel, and you would probably want to manage entire "icon themes" rather than replacing individual icons... which you can always do manually, if you are keen on that.

FWIW, I definitely still do not see it as a sidebar. The practical use of that escapes me. That one should be reserved for lists of tiddlers you need to open.

[morosanuae]

@tobibeer maybe you are right in some aspects but not all. Think about it. The proposed "System Images" tab case is similar to the case of "Tags" tab. Why do we need it other than management (inventory) operations? In the normal flow we tag a tiddler only in the edit mode. For that we don't need the "Tags" tab.

I consider the "More" tab a kind of insight to the internal structure (the usable one) of the wiki and I expect to find all the useful "bricks" than can help me build my preferred version of the wiki. I don't like the idea of going to Control Panel just to overview/search the entire collection of icons to find what I need. I want it to be right under my nose, to not forget that it exists and I can use it.

But I thinks this "visibility" problem of the entire stack of resources is a general problem. For example I want also a "Macros" tab, a "Widgets" tab in the sidebar, for inventory/management purposes. to help me plan more easily what I'm going to do.

[tobibeer]

Tags are jumping points to content and aggregate related content. icons don't have that power, usually. So, the tags tab is far from "managing inventory"... it is a spot to find content that belongs together grouped by a common context. So, the tags tab is intended for content exploration and so are most other tabs, except for the tools tab which provides a shortcut to certain most-used utilities.

The "insight to internal structure" literally is the ControlPanel, next to of course providing the tools to make TiddlyWiki behave how you want it, insofar as there is an option for that.

So, the sidebar is not for building, it's for finding and quick customizations, i.e. "I truly need to see it in my own language right now".

Of course should there be bundled, pluginified icon themes in the future, then there could as well be an icon-theme switcher in the Tools tab. But this hardly warrants a tab of its own (to me).

So, the real question is: What use cases are you truly after. What journey you think users (like you or me or the average Wiki enthusiast) are trying to make when it comes to icons or icon themes.

I see editing tiddler content, (via the toolbar) and I see changing a whole bunch to modify representation, globally (setup => ControlPanel).

[morosanuae]

@tobibeer It looks like we have different opinions and I guess there's nothing we can do about it :) What I really want is that many of the useful things to be easy accessible/discoverable, right at my finger tips, that's it! Nothing fancy here. And, at least for me, the Control Panel is not the quickest/nicest/friendliest utility for a quick overview/finding of system icons (and copying their names) especially when I'm in the middle of editing content. I don't mind if this will not gone make into the core, I just thought others will benefit from it, that's all.

[Jermolene]

Hi @morosanuae @tobibeer thanks for the comments. I have a few background thoughts:

• The sidebar, as originally conceived, was primarily focussed on navigation: presenting various lists and permitting the entries to be opened in the story river for further action
• The tag manager $:/TagManager, and the newer tiddler manager $:/Manager are part of a gradual move towards more elaborate ways to interact with tiddlers of particular types. The goal is to make the main manager be tabbed, with the tag manager one of the other tabs

With that in mind, and the comments above, I wonder if there isn't an argument for a $:/ImageManager that opens in the main story river and provides a complete suite of management capabilities for images. We can link to it from the top of the Types sidebar tab, and give it a new page control button.

If you're planning on incorporating further features to manipulate images then I think the manager route is the best way to go. The sidebar is fiddly and hard to read, and not the place for intensive interactions.

[morosanuae]

@Jermolene Yes, it's a great idea overall, but not exactly what I had in mind initially. I'm not sure how the proposed solution will solve my all my "problems". Even when your proposed solution will be implemented, I will still have the need to put the icon gallery and some info about them "nearby". Maybe this will solve the management part but not the quick access part.
Maybe we should have a general architecture design scheme with long term plans and design strategies, a clear direction of development. It should be a lot easier for anyone who want to contribute to the app development.

[TiddlyTweeter]

@Jermolene The sidebar is fiddly and hard to read, and not the place for intensive interactions.

It seems to me there are several inter-related issues here.

But easier presentation of LIBRARIES of ICONS would help overall. And with icons a visual navigator with options available on hover or suchlike is the easiest way. Just having icons shown without access to what to do with them would be pointless. SO, IMO, its not just showing them that is the issue, its HOW they need using that is the central issue. So what are the end aims?

I don't care where such a mechanism is so long as its "near enough to the surface" to find easily. Though on small screens having lots of images directly visible in the sidebar I think is not viable.

[morosanuae]

@TiddlyTweeter I believe that just showing all the icons (visually) in one easy accessible place is already an improvement/useful thing. In time, new functionality can be added, of course. I use icons a lot so a gallery/list with search capability in the sidebar for quick access is very useful for me. Maybe is not that useful for everybody, but that's a whole different thing. That's why we need an ideas site where actual users can vote, otherwise we'll be only a few (developers) that will make this kind of decisions.

But, in the end, I don't know if this tread will accomplish anything. Indeed, there are to many different opinions and inter-related issues and it's getting overly complex, so maybe I'll close it. Please, vote with thumbs up for staying open or thumbs down to close it.

[tobibeer]

more accessible and manageable system Images 👍, a system images tab... not so much.

Also, if there were core components in either the control panel or the editor toolbar, it would probably be simple to reuse them in a custom tab.

[Jermolene]

Hi @morosanuae sorry this has been a frustrating experience for you (and your work on #2912). I'm keen to learn from the experience and so would welcome your thoughts on the process.

Maybe we should have a general architecture design scheme with long term plans and design strategies, a clear direction of development. It should be a lot easier for anyone who want to contribute to the app development.

Sadly, we don't currently have the manpower to do that in an exhaustive way, but I'd certainly like to make it easier for contributors.

In the meantime, my advice has been fairly consistent over the years: develop new features as plugins, and wait until there's some feedback and reaction before lobbying to get them into the core.

[morosanuae]

Hi @Jermolene,

Sadly, we don't currently have the manpower to do that in an exhaustive way, but I'd certainly like to make it easier for contributors.

But don't you think that we should lay down the first brick at least? It doesn't have to be exhaustive, just few guidelines at start. What we aim exactly? And based on this we should discuss/vote and not on the issue pages. These are mainly for technical details I guess.

Example

_Main goals:_

• Stability
• High performance
• Compatibility with all devices
• Fully featured or lightweight (modular)
• Backward compatible
• etc.

_Design strategies (UI)_

• Story river or tabbed navigation
• Documentation location
• Only one sidebar or multiple
• etc.

_Roadmap_

• Renaming multiple tiddlers at once
• Image manager
• etc.

or something like that. I know there is a roadmap tiddler already but I don't know if it is enough.

In the meantime, my advice has been fairly consistent over the years: develop new features as plugins, and wait until there's some feedback and reaction before lobbying to get them into the core.

To be honest with you I really wish a truly modular app at a micro scale level. I said it before. The best way to please all the users is to let them to construct their on app (from modules/plugins). That means splitting the actual core into multiple plugins (or modules). If I want to use the "Explorer" tab I put it on my "compile" list otherwise not. I think that are so many users that use only the basic features of the app, maybe under 20% so why to bloat the app with things that they never use. And this will increase performance also.

Thanks and sorry if I said something stupid.

[Jermolene]

But don't you think that we should lay down the first brick at least? It doesn't have to be exhaustive, just few guidelines at start. What we aim exactly? And based on this we should discuss/vote and not on the issue pages. These are mainly for technical details I guess.

I think it's quite difficult to get such policies laid down in a way that is useful and will be easy to maintain in the future.

_Main goals:_

Those goals are all rather bland statements of intent: we'd all love to have full backwards compatibility, full device compatibility, or the highest performance. It's not that useful to write them down, because they'd apply to every project. The nitty gritty details is in how we approach trade-offs and decisions. And that stuff is highly specific to the case in point, and difficult to legislate in advance for.

_Design strategies (UI)_

What is this list intended to capture?

_Roadmap_

These sound like prospective individual features, rather than a road map as such.

or something like that. I know there is a roadmap tiddler already but I don't know if it is enough.

I'm sure it's out of date, which illustrates the problem of keeping these sorts of things up to date.

To be honest with you I really wish a truly modular app at a micro scale level. I said it before. The best way to please all the users is to let them to construct their on app (from modules/plugins). That means splitting the actual core into multiple plugins (or modules). If I want to use the "Explorer" tab I put it on my "compile" list otherwise not. I think that are so many users that use only the basic features of the app, maybe under 20% so why to bloat the app with things that they never use. And this will increase performance also.

It sounds like you want to explore non-standard builds of the core plugin. That's a goal that has come up before, and I'd encourage you to experiment if you're interested. I'm not so interested in supporting multiple versions of the core because of the impact that it has on support: suddenly, every question on the group would have to be accompanied by a detailed listing of the core version in use. Everybody using the same core makes things a lot easier (so you might take away from that that one of the goals of the design of TiddlyWiki is that it be easy to give tech support...).

One of the issues is that for TiddlyWiki, as every project, the scarcest resource is the attention of the core team. That's why I advocate independent innovation via plugins.

Thanks and sorry if I said something stupid.

Not at all.

[morosanuae]

Thanks for the info, I've learned something useful from this.
I wasn't involved that much in open-source projects in the past so I don't have a lot of experience. One thing I've noticed that I don't like: the community is a very big, heavy and slow dinosaur, that can travel only short distances in a considerable amount of time. I just thought things would be more dynamic around here.

[Jermolene]

Hi @morosanuae it's more complicated than that :smile: — some things can and do happen very quickly. But here we're looking at some thing that is both deeply complicated in its own right and interrelated to a number of other concerns. Arriving at consensus in these kind of areas is difficult. My sense is that you've been seeking strong confirmation from the community before you go further, and as I've tried to explain it's very hard to give an unequivocal answer when things are so inchoate.

Your earlier pull request to fix up the “explore” tab was a good example of a PR that could be processed much more swiftly.