-
Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.
If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.
- The Lone Wolf Development Team
Link colors for story and mechanics
- Thread starter AEIOU
- Start date
Dr_Automaton
Well-known member
+1, especially if it can be implemented as an optional toggle.
gloranphile
Well-known member
This is a great idea. In addition, World items could be a different color (this would greatly improve world-building vs. story building).
Another link color.... Can we pretty please have a color for an empty link. I've created stub topics as I go for content but sometimes I don't get back to those empty topics.
I half joke that perhaps it should be bold blinking red so that I get annoyed at it and add material sooner.
I half joke that perhaps it should be bold blinking red so that I get annoyed at it and add material sooner.
Zaphod Beebledoc
Well-known member
Maybe... Topics created using the quick create shortcut could automatically be a different colour?
Some thoughts on this stuff that I'm not sure you've considered...
1. Differentiating between world and story almanac has meaning right now. However, we've had plenty of folks asking for the world to included everything, including the story, so the story is merely a proper subset. If we do something like that, even as an option someone can enable, there's zero distinction between world and story. I guess we could now differentiate between story and "not story", but that has less meaning.
2. What's the definition of an "empty" topic? At the moment, there is no such thing as an "empty" topic. There is simply a topic with a bunch of placeholders that you may or may not have filled in yet.
3. Keying on a topic created via "Quick Create" is a poor way of identifying an "empty" topic. How is a topic created via "Quick Create" any different from a topic created any other way and then simply named by the user? Heck, topics created other ways don't even have to be named, so their arguably MORE "empty".
4. Let's say that a definition of "empty" can somehow be defined and agreed to. In order to determine whether a link is to an "empty" topic, we now need to check every topic to figure that information out. That will slow performance down or we have to cache all that info. Caching would work on the desktop client, but what about a web-based interface? At that point, caching isn't an option, so we'll have to check the status of every topic that is linked to in order to display all the links properly for TopicA. Our server load has suddenly spiked big-time and our performance goes into the toilet for all users.
There are times where ideas are really cool, but utterly impractical to implement. And I think this is one of them.
Differentiating between topics, articles, plot, journals, and notes would definitely be possible. However, I'm honestly not sure how much value that really brings to the product. The nature of a link will generally be pretty apparent from the link itself and its context. I'm sure there will be cases where that's not apparent, but what percentage of cases will that arise in? Unless I'm missing something (which you guys will hopefully enlighten me on), this is a feature that will be neat, but of comparatively limited value relative to all the other features users are asking for, so it's something that would be prioritized a good distance down the priority list.
So, is that an accurate assessment? Or what am I missing here???
1. Differentiating between world and story almanac has meaning right now. However, we've had plenty of folks asking for the world to included everything, including the story, so the story is merely a proper subset. If we do something like that, even as an option someone can enable, there's zero distinction between world and story. I guess we could now differentiate between story and "not story", but that has less meaning.
2. What's the definition of an "empty" topic? At the moment, there is no such thing as an "empty" topic. There is simply a topic with a bunch of placeholders that you may or may not have filled in yet.
3. Keying on a topic created via "Quick Create" is a poor way of identifying an "empty" topic. How is a topic created via "Quick Create" any different from a topic created any other way and then simply named by the user? Heck, topics created other ways don't even have to be named, so their arguably MORE "empty".
4. Let's say that a definition of "empty" can somehow be defined and agreed to. In order to determine whether a link is to an "empty" topic, we now need to check every topic to figure that information out. That will slow performance down or we have to cache all that info. Caching would work on the desktop client, but what about a web-based interface? At that point, caching isn't an option, so we'll have to check the status of every topic that is linked to in order to display all the links properly for TopicA. Our server load has suddenly spiked big-time and our performance goes into the toilet for all users.
There are times where ideas are really cool, but utterly impractical to implement. And I think this is one of them.
Differentiating between topics, articles, plot, journals, and notes would definitely be possible. However, I'm honestly not sure how much value that really brings to the product. The nature of a link will generally be pretty apparent from the link itself and its context. I'm sure there will be cases where that's not apparent, but what percentage of cases will that arise in? Unless I'm missing something (which you guys will hopefully enlighten me on), this is a feature that will be neat, but of comparatively limited value relative to all the other features users are asking for, so it's something that would be prioritized a good distance down the priority list.
So, is that an accurate assessment? Or what am I missing here???
The new "Utility" tag is a candidate?
If it is present, and set to Empty or Incomplete or Placeholder (or even just present), then the link is shown in the "empty/incomplete" colour?
...
And then I read your article too quickly, Rob.
The scanning is the very slow bit :-(
Unless the link state only gets updated when you rescan the links in your topic(s) (not ideal, but at least then only done at explicit times).
I assumed that we'd set a flag on topics when they were saved. The issue is that we now need to check the status of every topic to which there is a link when rendering all the snippets. Let's say we have TopicA with a few dozen snippets, and those snippets contain links to TopicB through TopicZ. Instead of just retrieving TopicA for display, we now have to ALSO check the status of TopicB through TopicZ.
On the desktop client, we can do that by increasing our memory footprint and caching the extra information. On the server, we can't cache everything, so we have to retrieve that status of TopicB through TopicZ from the database. That can get VERY expensive in terms of performance, which slows down the system for everybody.
That's where the problem arises and why I think this is a cool idea but impractical to actually implement.
Hope this makes more sense this time!