Link colors for story and mechanics

[Fox Lee]

I'd vote for both suggestions (though not for blinking text - 90s web flashbacks aaaaugh).

[Mead]

I like these ideas...

I especially like the idea of a different color for an empty topic.. but I think since the topics aren't really empty to begin with... most come with certain things already chosen... that one may be harder.

[Zaphod Beebledoc]

Maybe... Topics created using the quick create shortcut could automatically be a different colour?

[rob]

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???

[Farling]

Originally Posted by rob

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.

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).

[rob]

Originally Posted by Farling

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!

[weogarth]

Valid performance points, Rob. Thanks for pointing it out.