The screenshots in this case study are not from the final product, as launched. (I have attempted to recreate it on my server as a sample.) Hence, image URLs are broken, there is scarce example content, some additional features are not depicted, and you'll notice minor tweaks incomplete (like alignment of one registration form field). If you would like to sample this reconstructed site through Drupal UI, I can create a temporary login for you. NOTE: The site is offline now. I am told that they intend to roll it into the parent site.
This website was built in Drupal 6. At the time, the necessary Drupal 7 contributed modules were not mature enough. Also, the association's parent site -- built prior, was in Drupal 6. I was the entire development team. The project was completed in about 2-3 months.
Client Objective: Create a member-only wiki for their journalist membership that would provide a wealth of "insider" data for each country. Information that field reporters could use to help them more easily and safely work in a given territory, such as: government agency personnel that were supportive of journalists; vetted drivers and interpreters; best money exchange places; good hotels, restaurants, bars; etc. Apart from a Country Overview and Fact Sheet, which was to be viewable by non-members, the data would be built by the members -- citizen journalist journalism.
Members would register for the site, then be vetted as legitimate media. When registering, they would pick a desired region, which would become their home 'group'. They could request to join other groups/regions, based on approval.
Client wanted the site to be a guided site -- limiting options for the user, until they made certain choices first to narrow their focus.
The development grant required that some information be made public, which was limited to a Country Overview and Fact Sheet.
Because the site would contain highly-sensitive information, it was important to keep the public and private parts of the site separated. All prospective members were required to register and complete a brief profile so that they could be (manually) vetted before membership approval. Login security module was used to lock out failed login attempts beyond a certain number. The OG Groups module was employed. Users were required to 'join' a specific group (Region), with request for additional ones. CCK and Views were used heavily, and access control was established through Views as well as through the Access Control module for individual content items.
Information and functionality were limited pending membership approval. Pending-members had full access to complete their detailed profile.
Once approved, member's page would display their Region(s) [Drupal OG Groups] as a link to that area, as well as a sidebar with links to contributing the various types of content. All blocks all collapsible, with open states as desired to incentivize action.
Full profile information was important to help establish credibility of the contributed material. The Content Profile (?) module was used to report the completion of profiles. When a member fully completed their profile, they would be promoted on the site with a breakout box showing their photo and bio snippet. [This was not in the client's original feature requests. It was my idea. I added several other bonus-added features like this throughout the site.]
For logged-in members, in addition to the My Regions block, a Connect With Others button was available to view the Members Directory with multiple search filters. (Later phases were to include on-site IM.)
Notice that throughout the site, members are encouraged to complete their profiles by the haunting of the Complete Profile call-to-action button on the sidebar.
Blocks & Modules
Just a peek at the blocks used on this site. (Normally, I use Context module to better/further manipulate blocks, as I did with the final.)
Country Information: Collection
For initial launch, OPC wanted to start with 4 countries. While the site was designed with all Regions [OG Groups] and all Countries [Taxonomy], only 4 were made available in the UI selection process to ease members into the system.
Registered users could add content for the various wikis (see Figure 4). A number of custom content types were created to build the wikis, as well as other site information. The Voting module was used as a mechanism for other members to rate ("like") wiki entries.
As is my style, special attention was paid to the UI/UX to be sure that input was controlled and that field descriptions were clear. Wiki forms where quite extensive to produce in-depth information.
CHALLENGE: Throughout the project, the client (my liaison) admittedly couldn't quite wrap her head around how this was going to work structurally. She was stuck with the thought of it being one field of long narrative -- more akin to a Wikipedia page, I suppose. I really fought this, insisting that the site needed well-defined fields so that specific information could be easily searched and aggregated. (After all, that is what a good database application does!) I pointed out that the comment feature could be used for members to swap anecdotes; however, users should always be encouraged to add hard data (also) as a wiki entry. Example: Rather than simply entering a comment about one's favorite restaurant in Cuba, user was instructed to create a wiki entry for that restaurant under Food & Drink topic. Now, talking about how you got loaded in the bar with Wolf Blitzer is perfectly good fodder for the comments section. As a compromise, each wiki entry did have an open field for "notes".
NOTE: If I had built the site the way that she envisioned (as a narrative free-for-all), it would have been quicker and easier development. Instead, I built it the proper way (IMO) -- well-structured, flexible, dynamic, scalable...and for the same time/money even!
Country Information: Display
Another technical challenge came with the design itself.
CHALLENGE: The design for the site was done by an agency, with only a PSD file made available to me for graphical elements. For designers (who are not also developers), the possibilities are endless. The agency, along with the client, envisioned each country having only 1 main page, with embedded tabs of the specific information sections. I never discussed with the client whether they were flexible about this design choice, I just embraced the challenge of it! While it is easy enough to do this in Views, a very kludgy implementation of Views menu tabs and custom pathing made it challenging. See more discussion below.
When a member clicked the country link, in their My Regions block, this one page would load with views for: Overview*, Facts*, Discussions, Wikis, Photos. The Overview was to be written, via OPC's invitation, by a journalist that covers a particular country. The Facts page would be created by OPC staff. The Discussion comprised the member anecdotal information, i.e., comments. The Wiki page provided a dropdown menu [Views exposed filter] for member to select a topic to display all the entries for that topic -- example "Food & Drink", which were member contributed entries. The Photos page likewise was member contributed content.
* These were the only two 'pages' [Views] available to the public.
Country Information: Backend Systems
I certainly did not intend to build a different set of Views for each country! So, I set out to design 1 set* of Views that would be build on the fly all pages, depending on the taxonomy argument/value passed to the View by the clicked menu URL.
* an individual View for each tab, plus associated attachment Views
CHALLENGE: The biggest problem was that OG Groups (at the time) did not have the capacity to pass in the OG Group argument from the URL. Dynamically selecting the country was not a problem, as that was all taxonomy and easily passed in via the Taxonomy Menu module. However, the whole experience was driven by Region/OG Group. Client wanted the Regions to have autonomy, so that a member only saw data and navigation pertaining to their selected Region. Technically, I could manually select a Views OG Group relationship, but not use a dynamic variable.
CHALLENGE: As I progressed in my attempts at a dynamic Views set to be used by all countries, I was faced with one final annoying challenge. While I now could dynamically generate the tabbed pages, and remain Region-centered, Views would show a 'parent' tabbed page of ALL results for that country -- an undesired mile-long page of overview, facts, discussions, wikis entries, and photos combined on screen. A shortcoming of that feature of Views. Attempts at simply hiding this page via CSS were unsatisfying. I did also try using Quick Tabs module, but encountered same issues. You can read more about the technical drawbacks from my Drupal.org posts/issues if you are really hungry for more! https://www.drupal.org/user/338895/dashboard
I researched this for weeks and weeks, and tried so many iterations of Views to accomplish the objective. I even reached out and stumped the Views module developer (The Great and Powerful Merlin of Chaos) on this one -- along with others. I did finally resolve it! Perhaps, I shouldn't give up my trade secret quite so easily, now should I. *wink* You'll have to hire me to learn the secret!