FreeOrion

Forums for the FreeOrion project
It is currently Mon Oct 23, 2017 11:49 am

All times are UTC




Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Wed Apr 11, 2012 5:12 pm 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
Navigating the 'Pedia is pretty important to the game, unless you have a photographic memory. Unfortunately, in it's one-window incarnation, it's not very easy to get around.

The following design is modeled after the most user-friendly in-game 'pedia i've had the pleasure to use-- a modded Civ IV 'pedia, though i'm sure you can find similar designs elsewhere.

The sidebar on the left provides both context and quick navigation, allowing you with a single click to go back to the start, or to select a parallel topic. The result of any click is much more obvious and predictable than "Up," "Back," or "Next" buttons.

This is not a pixel perfect example, but the basic idea.
If we committed to only two levels of headings, the "Up" button could be more clearly labeled "Back to Index" or some such.

The disadvantage is that it takes up a bit more space vertically-- which is important in the production, research and design screens. In these contexts the "galatopedia" heading could be dispensed with, resulting in an equally vertically-efficient design.

Attachment:
Galactopedia1.jpg
Galactopedia1.jpg [ 76.74 KiB | Viewed 5255 times ]


Attachment:
Galactopedia2.jpg
Galactopedia2.jpg [ 115.91 KiB | Viewed 5255 times ]


Attachments:
File comment: should have put a scrollbar in the species panel here.
Galactopedia3.jpg
Galactopedia3.jpg [ 132.82 KiB | Viewed 5255 times ]

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—
Top
 Profile  
 
PostPosted: Sun Jun 02, 2013 8:58 am 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
I would like to pick this up, but I have some questions regarding this:

  • Galactopedia2.jpg and Galactopedia3.jpg show an arrow button(?), what would be semantic of it?
  • You said the Header would consume too much space, what about the section header (For example 'Index' and 'Species' in Galactopedia2.jpg)? Are those really needed?
  • Should the index be a plain list? What about using a accordeon or a tree UI pattern to mix both vertical navigation (sub- to supercategory or the other way around) and listing?

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Top
 Profile  
 
PostPosted: Sun Jun 02, 2013 9:14 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12004
Location: Munich
I assume the ↺ is the back button, which would go to the previously shown entry.

Before implementing this, I'd suggest considering how to add UI support for a text search function.


Top
 Profile  
 
PostPosted: Sun Jun 02, 2013 4:01 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4371
Geoff the Medio wrote:
Before implementing this, I'd suggest considering how to add UI support for a text search function.
Perhaps what is currently called 'Index' should really be considered as the top level of 'Contents' (and a tree structure for that such as adrian suggests would be nice), and then there could be a comprehensive index page, which lists things not just by primary title but also by alternate title and major-referenced-concepts. That would reduce the need for a text search, or a text search could be keyed off that comprehensive index list rather then needing to be a full text search.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Sun Jun 02, 2013 4:33 pm 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
adrian_broher wrote:
I would like to pick this up, but I have some questions regarding this:

Excellent.

adrian_broher wrote:
Galactopedia2.jpg and Galactopedia3.jpg show an arrow button(?), what would be semantic of it?
Geoff's right, that's a "Back" button like in a browser.

adrian_broher wrote:
You said the Header would consume too much space, what about the section header (For example 'Index' and 'Species' in Galactopedia2.jpg)? Are those really needed?
That seems to me to be rather useful context.

adrian_broher wrote:
Should the index be a plain list? What about using a accordeon or a tree UI pattern to mix both vertical navigation (sub- to supercategory or the other way around) and listing?
The accordion would i think just get in the way. When a heading is expanded there usually a lot of entries underneath, not a neat little paragraph. Though the accordion could be useful in the article itself, in some cases (like species articles) where there's a lot of text)

The tree seems like the wrong interface for this use-case. There's no need to compare where different articles sit in the hierarchy, or to drag "files" from one location to another. In short i don't see a tree providing anything useful to this context.


Geoff the Medio wrote:
Before implementing this, I'd suggest considering how to add UI support for a text search function.

Search sounds good to me. It is increasingly the way people are used to "navigating" information, and in sometimes will be the easiest way to get around.

Dilvish wrote:
Geoff the Medio wrote:
Before implementing this, I'd suggest considering how to add UI support for a text search function.
Perhaps what is currently called 'Index' should really be considered as the top level of 'Contents' (and a tree structure for that such as adrian suggests would be nice), and then there could be a comprehensive index page, which lists things not just by primary title but also by alternate title and major-referenced-concepts. That would reduce the need for a text search, or a text search could be keyed off that comprehensive index list rather then needing to be a full text search.

I'm not getting a clear idea of what you are proposing. Are you saying you want to rename what's labeled "index" in my mockup but leave it unchanged, and then add a new sort of page called index? The new index being pretty much exactly what an exhaustive index in a book would be, except with hyperlinks?


When we settle what we want, give me a few days to create some refined mock-ups. That should be more efficient all around, rather than trying to iterate layout/design stuff in code.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Sun Jun 02, 2013 7:47 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4371
eleazar wrote:
Dilvish wrote:
Perhaps what is currently called 'Index' should really be considered as the top level of 'Contents' (and a tree structure for that such as adrian suggests would be nice), and then there could be a comprehensive index page, which lists things not just by primary title but also by alternate title and major-referenced-concepts. That would reduce the need for a text search, or a text search could be keyed off that comprehensive index list rather then needing to be a full text search.
I'm not getting a clear idea of what you are proposing. Are you saying you want to rename what's labeled "index" in my mockup but leave it unchanged, and then add a new sort of page called index? The new index being pretty much exactly what an exhaustive index in a book would be, except with hyperlinks?
That's the major portion of it, yes. Regarding a tree structure for the left panel, I like the fast navigation that a tree facilitates, not restricted to just the hyperlinks in the current article. A search function would accomplish a lot of that (perhaps at the expense of requiring more clicks), but the tree structure is also an outline of the content, which I personally find helpful.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Mon Jun 03, 2013 3:56 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
eleazar wrote:
Geoff's right, that's a "Back" button like in a browser.

Okay, thanks for clarification.

eleazar wrote:
The accordion would i think just get in the way. When a heading is expanded there usually a lot of entries underneath, not a neat little paragraph. Though the accordion could be useful in the article itself, in some cases (like species articles) where there's a lot of text)


I attached an example of what I had in mind, because it doesn't seem like I could explain it properly:

Attachment:
galactopedia.png
galactopedia.png [ 59.3 KiB | Viewed 5038 times ]


On the left side you see the navigation, implemented as an accordion. The accordion headers only show the ancestors of the current article, with the sorted by increasing distance to the root, which gives you your absolute location in the galactopedia.

If you click on a accordion header you will be put to the according index and list it's children. For example the middle illustration shows how the index would look like if you clicked on the 'Subcategory' header. The right illustration shows the same for a click on 'Category'.

This design eliminates the need for an explicit up button. It gives the location of the article and the possibility to navigate between the sibling articles with possible similar means and upwards to more general concepts.

Below the navigation you will find a place for a free text search field.

The right side, the article view doesn't change from your proposal.

eleazar wrote:
The tree seems like the wrong interface for this use-case. There's no need to compare where different articles sit in the hierarchy, or to drag "files" from one location to another. In short i don't see a tree providing anything useful to this context.
You're probably right, also this would introduce a lot of horizontal scroll given the possible indentation of the tree.

eleazar wrote:
When we settle what we want, give me a few days to create some refined mock-ups. That should be more efficient all around, rather than trying to iterate layout/design stuff in code.


I'm looking forward for you ideas.

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Last edited by adrian_broher on Mon Jun 03, 2013 9:15 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Jun 03, 2013 9:13 pm 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
OK, first off what i labeled as "Index" in the original mockup, at least by publishing standards isn't an index. The label "index" more properly belongs to what Dilvish describes.

Though i don't see benefit in implemented what is essentially an analog book-style index in a computer game. Surely search and/or a hierarchical categorization are more useful than a big long alphabetical list of everything? Or are you mostly thinking of the benefits of such an index in implementing search? I have little to say about how it should work behind the scenes.

adrian_broher wrote:
I attached an example of what I had in mind, because it doesn't seem like I could explain it properly:

Yeah, i was responding to a different idea. This one makes more sense.

Out of time ATM, response soon.


P.S. another thing to consider is allowing an article to live in more than one location, without simply scripting a duplicate article. In my experience with other in-game 'Pedias sometimes there's more than one subcategory and article reasonably could fall under. It would be nice to give the player the benefit of the doubt, and show him the article in all reasonable places, rather than make him hunt for it.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Mon Jun 03, 2013 10:26 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12004
Location: Munich
I'm skeptical about the need for tiered categorization of pedia articles (category, subcategory, subsubcategory, etc.) or multiple independent categorization (category1, category2). Either of these will makes things more complicated to store, display, an script, and when is it really necessary to subcategorize things?

I agree that a simple alphabetical index isn't of much use, but there's not much more benefit to having a list of Ships techs rather than a list of tech. Or if there is, this could be implemented as two separate categories, rather than adding the scaffolding for subcategories... That is, there'd be a "techs" category, and a "ships techs" category. The former could have a link to the latter, but there wouldn't be an "up/down" relationship between them.

For multiple categorization, if the motivation is to avoid having to double text in the stringtable file in order to have an article that absolutely needs to be listed in multiple categories, the article could be duplicated just by using a stringtable reference, without need to actually have it typed out twice.

If at all workable, I'd suggest having a full text search, rather than an indexed-only search. I've never found the latter to be of much use, as if one knows the article title, there's not much need to search for it.


Top
 Profile  
 
PostPosted: Tue Jun 04, 2013 8:49 am 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
eleazar wrote:
Or are you mostly thinking of the benefits of such an index in implementing search? I have little to say about how it should work behind the scenes.

For me this discussion is only about the UI design. The implementation is a complete different aspect and should follow the UI design.

Geoff the Medio wrote:
I'm skeptical about the need for tiered categorization of pedia articles (category, subcategory, subsubcategory, etc.) or multiple independent categorization (category1, category2). Either of these will makes things more complicated to store, display, an script, and when is it really necessary to subcategorize things?

There is not need, this structure is already in place. Take a look at the attached graph. That's how the encyclopedia is already organized now.


Attachments:
encyclopedia.png
encyclopedia.png [ 662 KiB | Viewed 5010 times ]

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Top
 Profile  
 
PostPosted: Tue Jun 04, 2013 9:10 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12004
Location: Munich
adrian_broher wrote:
Geoff the Medio wrote:
I'm skeptical about the need for tiered categorization of pedia articles (category, subcategory, subsubcategory, etc.)...
There is not need, this structure is already in place. Take a look at the attached graph. That's how the encyclopedia is already organized now.
I'm not sure what you mean by this... When I open the encyclopedia, there is a "Technology" entry in the index, which takes me to a list of all techs. There's no "Learning Technologies" list. And if there was, as far as I know, it would just be a top level list article, not actually "contained" within another category in any meaningful sense.


Top
 Profile  
 
PostPosted: Tue Jun 04, 2013 5:48 pm 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
I don't know if the number of subcategory levels needs to be determined, if the additional effort is reasonable, it would be good if they system supported multiple subcategories. Though we should keep in mind that we currently use a pretty flat hierarchy, and are very unlikely to use a hierarchy with a bunch of levels. We don't need a GUI that supports 8 levels of hierarchy optimally.

Also i'm confident that search and hyperlink are going to be the vastly more common way players interact with the 'pedia. The hierarchical list is still better for some uses, especially if you want check out something like how many specials or species there are. But that's not the main thing.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Tue Jun 04, 2013 10:37 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12004
Location: Munich
I'm concerned more about how to notate and store the multi-level categorization than about how to display it. Presently things are just given a single category in the encyclopedia.txt script, and it's not obvious how to set up multiple layers. Any existing appearance of multiple layers is (I think) a combination of scripted and engine-generated articles (including the index page) that are just a list of links to other articles.

Multiple parallel categories might be easier, as the articles could be given a list of category strings, rather than a single string as is the case now.

But practically, how many articles are going to be hand-written such that there needs to be hand-written multiple category layers or even multiple parallel categories for an article? It sounds potentially useful, but really how necessary would it be in practice? Is there a list of needs-to-be-written pedia articles that don't make sense with only a single category layer?

I suppose if someone really wants to write it, fine, but it seems like a waste of time / complexity to me...


Top
 Profile  
 
PostPosted: Wed Jun 12, 2013 2:38 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
I'm a bit lost, what is the current status now? Eleazar, do you still plan to create those mockups?

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Top
 Profile  
 
PostPosted: Tue Aug 12, 2014 2:45 pm 
Offline
Space Squid

Joined: Mon Jul 21, 2014 11:56 am
Posts: 53
I am doing some work on Pedia, it's here: viewtopic.php?f=6&t=8951&p=71288#p71288

_________________
Code, justify, code - Pitr
Attached patches are released under GPL 2.0 or later, artwork and such are released under CC-BY-SA 3.0 license.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group