LANDING  PAGE  (NOT  A  GUILD MEMBER) 

This is the landing page for guilds if the user is logged in but not a member of a guild. 

1. Primary title is “Guilds”.  Secondary title is also “Guilds”. 

2. Epic banner showing lots of people doing stuff.  Should also have the word “Guilds” on it as well as a teaser line or call to action.  Recommended: regular text for the text here, with shaded bars baked into the image for contrast. 

3. Dashboard of three major statistics offering a compelling social proof that people should participate.  These should be real text over individual, related, exciting backgrounds.  These should be live, or close to live.  Recommended: have a way to A/B test what stats are shown and see what stats drive signups the most.  Recommended: animate the backgrounds, the display of the text (sliding in, fading in, flashy incrementing, something), and have the dashboards update in real‐time. 

4. “What are guilds” text.  Not “what are we launching,” but what a guild is and why you’d join one.  All real text.  Includes prominent link to the FAQ.  This is an important call to action.  Recommended: the FAQ link be big text and a big link with traditional link styles over an image. 

5. Primary call to action. Guilds: “find yours.”  Also help text of “start your search quickly” or equivalent.  Right‐aligned.  Recommended: call to action text that ties together the header text with the search. 

6. Five large vertical lozenge buttons which are primary calls to action.  Buttons are prefilled submissions to the search form, with the text and submission parameters able to be dynamically updated without a build.  Recommended: have a way to A/B test what buttons are shown and see what buttons are used most (accounting for position bias).  Recommended: buttons should be graphical backgrounds with real text and echo the “Lord Kitchener wants you” style, plus have normal button affordances (hover, press, depress states). 

1 

2 

3 

4 

5  6 

LANDING PAGE  (NOT  A GUILD  MEMBER),  CONTINUED 

1. Following the primary lozenge buttons is a right‐aligned second label (matching the help text style) to “find by name.”  To the right, left‐aligned with the lozenge buttons, are two text input search fields, one for guild name and one for leader or member name.  Typing in one clears the typing in the other, so you can only submit one.  As accounts can only be in one guild at a time, a successful result for leader or member name should take you to the guild roster page.  If a search is done for guild name and only one is found, it should take you to that guild’s home page.  If more than one guild is found, it should take you to the search results page listing them all.  If both are submitted with content (through bypassing of the JavaScript or lack of validation), it should be treated as an OR and take you to the search results page.  Recommended: inline autocomplete all guild names and leader/member names.  Recommended: offer alternative spelling suggestions in the autocomplete based on metaphone or double metaphone encodings. 

2. A third right‐aligned label prompting for a “detailed search.” To the right, left‐aligned with the previous controls, a link to the search filter page. 

3. “Why start a guild” text. This should include some mention of the obligations and responsibilities incurred in running a guild, including promotion and links to what running a guild in‐game will be like.  All real text.  Includes prominent link to the guild creation page.  Recommended: the creation link be big text and a big link with traditional link styles over an image.  

4. Pervasive guild footer.  This is present on every guild page, including individual guild home pages and forums.  Links to guilds home (this landing page), guilds FAQ, guilds search and guild creation.  Recommended: personalization: if the user is a member of a guild, a “your guild” link comes first, before “guilds home,” linking to the user’s guild. 

1 

2 

3 

4 

GUILD  SEARCH 

1. Secondary header here is “Guild search.”  Epic banner showing lots of people doing stuff.  What does it look when someone is looking for a group?  Should also have the word “Guilds” on it as well as a teaser line or call to action.  Recommended: regular text for the text here, with shaded bars baked into the image for contrast. 

2. “Encourage the user to search” text. Include the total number of guilds, updated live (or relatively so).  Explain what a user might look for in a guild.  All real text.  You might want to link to the guild FAQ, but I’m not sure it’s explicitly necessary. 

3. A dynamic statement of what the user is currently searching for, including the number (or approximate number for the search narrowing page) returned in this search.  This sentence reflects all the search terms selected.  It is terminated by a “Narrow this down” button or equivalent; note that it should not be a “Search” button but rather a “Filter” button. 

4. Table of search results, showing the most important fields as headers and inline: Name, Allegiance, Play Type, Time Zone, Language, Members and Leader, sortable by these columns.  Rows alternate color.  The entire row is clickable; this clickability of the top line of information persists even when the row expands. Grayed out row content is for guilds that are not recruiting. Recommended: rather than paginating a fixed list of e.g. 20 items, use a scrollable area with an infinite scroll to load in the next N items when you get near the bottom via AJAX. 

5. Pervasive guild footer.  This is present on every guild page, including individual guild home pages and forums.  Links to guilds home, guilds FAQ, guilds search (this page) and guild creation.  Recommended: personalization: if the user is a member of a guild, a “your guild” link comes first, before “guilds home,” linking to the user’s guild. 

1 

2 

3 

4 

5 

GUILD  SEARCH  (FILTERING) 

1. This is the same page as the previous guild search results page.  Selecting “Narrow this down” hides the status line and the search results pane and displays this filter pane.  The “Narrow this down” button is removed from the status result line and becomes the action button for the primary form submission, so it is important the wording works in both places. 

2. Filter selection. These are search criteria for guilds, where the rendering is that of sentences with “fill‐ins” that are search options.  They’re really just fancy checkboxes which function as boolean parameters, and checking no option is the same as checking all options.  Each drop down is an OR, with all the options ANDed together.  The sentence format will require extensive review by Community as well as potentially complex translations. 

3. Only four options are visible by default: allegiance, server type, language and time zone.  The rest are hidden behind this drop‐down. 

4. The user can explicitly search for only guilds that are currently recruiting.  This is not the default. 

5. The search button submits the search request to Platform, slides the search results panel back in, and updates the status line and search results box with the results.  For Platform submission, selections within a group are OR, selections of multiple groups are AND, e.g. SELECT * FROM guilds WHERE (allegiances = republic OR empire) AND (playtype = pve OR rppve).  Recommended: this be an AJAX transaction. It doesn’t explicitly need to be (whereas the switch from search results to the search form does), but it should be. 

 

1 2 

3 

5

4 

GUILD  SEARCH  (FILTERING),  CONTINUED 

6. The status result line changes live to reflect the selections made in the filter pane: 

There are 1400 guilds. 

User selects “Empire.” 

Around 900 guilds match these options. 

User selects “Player versus environment.” 

Around 732 guilds match these options. 

etc. Platform will provide the data for each combination of checkboxes, so the status line can be updated live while selections are being made.  This approximate figure will be replaced with an exact figure when the search is made and the exact number is returned.  (This new number should then repopulate that combination metric on the Platform side with no additional interaction from the Drupal side.)  The “around” qualifier and approximate figure are replaced by the real figure and real selections on the search results page. 

7. Advanced search by name. This is a separate, specific, actual search, not a filter.  It should reflect the same wording and style from the guild landing page, and be separate from the rest of the filters.  There are two text input search fields, one for guild name and one for leader or member name.  Typing in one clears the typing in the other, so you can only submit one.  As accounts can only be in one guild at a time, a successful result for leader or member name should take you to the guild roster page.  If a search is done for guild name and only one is found, it should take you to that guild’s home page.  If more than one guild is found, it should take you to the search results page listing them all.  If both are submitted with content (through bypassing of the JavaScript or lack of validation), it should be treated as an OR and take you to the search results page.  Recommended: inline autocomplete all guild names and leader/member names.  Recommended: offer alternative spelling suggestions in the autocomplete based on metaphone or double metaphone encodings. 

7 

6 

GUILD  SEARCH  (FILTERING, EXPANDED) 

1. This is the same page as the previous guild search results page, with the “View more options” drop‐down having been clicked, revealing the remainder of the options. 

2. Filter selection. These are the additional search criteria: roleplay, seriousness, focus, conversation, age, scheduled play, voice chat, forum and website use, chatty and casual. 

3. The “View more options” drop down slides down with the items and becomes the “slide up” button, changing its text to “View fewer option” as well as the arrow direction.  Sliding it back up again unsets all of the options, returning them to their all/nothing defaults. 

 1 

2 

3 

5

GUILD  SEARCH  (FILTERING, CHOICES) 

1. This is the same page as the previous guild search results page, with the “any type of” button having been clicked, revealing the options for that word choice.  All word choices work the same, only the choices differ. 

2. Word (option) selection.  This is a dialog box with a group of checkboxes, one for each choice. Checking all of them works the same (on the back end) as checking none of them, as the choices are OR and you cannot find a guild that has not made any selection at all.  (Technically, this means the “Check all” and “Uncheck all” buttons are redundant, but I haven’t decided if it’s better to remove one of them, and if so, which one.)  There is also an “X” close button to close the dialog. 

1 

2

GUILD  SEARCH  (FILTERING, SELECTIONS) 

1. This is the same page as the previous guild search results page, with the “player versus environment” and “roleplaying player versus environment” checkboxes having been checked.  Note the replacement of the “any type of” button with the actual selections made (also as buttons) and an “or” between them, expanding the length of the sentence onto a second line as necessary, pushing the entire form down, lengthening the dialog as necessary.  These additions and removals happen as boxes are checked and un‐checked.  In addition, whatever “selected” effect was applied to the “any type of” button is also applied to the newly added buttons.  Hovering over one button or clicking one button also replicates any effects to all associated buttons. 

2. Word (option) selection.  Once spawned, this dialog box does not move, even if it overlays added buttons or text.  When closed and reopened, it spawns at the lower right corner of the clicked button. 

1 2

GUILD  SEARCH  (REFINED,  EXPANDED)  

1. This is the same page as the previous guild search results page.  Because the page is the same, the URL is the same, which means to allow users to link to specific search results, we must use fragment identifiers.  The order of this is: 

# 

short, unique term and sort identifier (casual, light, family for casual, light roleplaying, family‐friendly), each separated by a hypen 

(if the user has expanded a specific guild) / 

(if the user has expanded a specific guild) guild ID number or unique identifier.  If more than one guild is expanded, the identifiers can be separated by hyphens. 

The fragment identifiers should not be name/value pairs, e.g. #sortby:name‐light_roleplaying‐etc.  A single, unique term for each potential filter type and sort option, with logic in the view to apply the search and sort correctly.  The specific keywords are undefined. 

2. After a search filter selection has been performed and results have been returned from Platform, the status line is updated with the accurate count of results as returned, plus allowing the user to clear individual search terms inline without using the entire form (but causing a new search unless you can think up a clever way to just strip out those particular results). 

3. Clicking on a row expands it.  The entire row is clickable; toggling between normal and expanded views; the expanded area is not clickable, except for parts that are actual links.  The expanded area includes a specific message as to whether the guild is currently recruiting or not, a small version of the guild logo, the guild description, the tags the guild describes themselves with, and a link to visit the guild home page. There is no way to expand all rows, but more than one row can be expanded at any given time. 

2 

3 

1 

ROSTER  (APPLICATIONS, FILTERING) 

This search filtering dialog works exactly the same as the main guild search filtering dialog.  There are fewer options because the only searchable options for applications are class, time zone, days and times. 

ROSTER  (APPLICATIONS, FILTERING,  SELECTIONS) 

This search filtering dialog works exactly the same as the main guild search filtering dialog.  There are fewer options because the only searchable options for applications are class, time zone, days and times. 

The only important thing to note is that some guild applications may not have any data (they were auto‐accepted into the guild, for example).  Having no data is not the same as being undecided, but for purposes of the search, anyone without a class selection should be counted as undecided. 

ROSTER  (APPLICATIONS, FILTERED)  

1. After a roster filter selection has been performed, the statement is updated with the count of results as returned, plus allowing the user to clear individual search terms inline without using the entire form. 

1