Drupal tasks to finish LOTE3 minisite

Ok, guys, we put in a full Saturday but the minisite is coming together. Most of the pages, contentwise, are finished, online and accessible from the menu. What we still need from the tech side:

  • add a view to the home page with three random avatars of people coming to \#LOTE as by page 1 of this document. DONE
  • in the single post view (for the minisite only), get rid of the useless stuff: name and avatar of the author, etc. I see you are doing this already, so this is fine. Some of that stuff (" Group content visibility – Use group defaults") I would even delete in the normal view for a node, site-wide. DONE
  • get rid of the right column in the posts. We go for a 1-column layout with one picture or embedded media on top + some text per page (save for the Participate page, that has the table with avatars). DONE
  • look and feel: re-assign to the normal Edgeryders website style sheet, with white background, Helvetica font etc. DONE
  • issue: the home page picture (inserted by panelizer override) is not visible to unlogged-in users. DONE
  • get rid of the header bar – or rather replace it with a different one that uses the Edgeryders, the MT2019 and the unMonastery logos. IN DISCUSSION - see comments
  • (optional) redirect http://lote.unmonastery.eu to edgeryders.eu/lote3 IN DISCUSSION - see comments

Look and feel

“look and feel: re-assign to the normal Edgeryders website style sheet, with white background, Helvetica font etc.”

I consider this done already. We have white background etc., and the few changes done by Dorotea are mostly reasonable improvements for a single-column website (such as a larger font size). And since there’s basically no connection to the rest of the edgeryders.eu website, it’s not important to have it 100% the same anyway …

Agree (almost)

Agreed. Only one thing: the menu is now green – really at odds with everything else. Could you make it red, and align it left? Everything will then become a little monochrome, but we can correct for this by putting in color pictures instead than B/W ones. Also, the header will have three logos in color (Edgeryders’ is mostly red, MT2019’s mostly blue, unMon’s green.

I meant black, not red :slight_smile:

Nadia thinks black is better than red… so, please, same thing but black.

Black is the new red.

Here we go.

Image access issue

“issue: the home page picture (inserted by panelizer override) is not visible to unlogged-in users.”

This was because the image was uploaded to a Document node in the “Making LOTE3” group. Documents are by default access conztrolled, which is reasonable for private groups. (The “Making LOTE3” group is public though, but there were some issues with access as non-logged-in user to public group content, which I guess triggered this issue.)

Since a few weeks, we have a nice image uploader accessible via clicking the “Insert Image” button in the editor and then “Browse server”. That’s the best / recommended way to upload public images now, avoiding all access issues. I have migrated the image from the document to this normal image storage, and also scaled it to max. vieable size and saved with a bit lower JPG quality (reducing file size by 75%).

I see

Yes, I see it. Even though you really have to be very tidy, because there is no “search” functionality! Is there a default archiving order? For example, do the images attached to different blog posts get inserted in a “blog” folder? It seems that everything is in /sites/default/images/ and have names like “16866_104191302932742_100000256180035_107780_5480795_n.jpg”. I wonder if we could find a way to archive this stuff a little better… anyway I get it, thanks.

Images are a mess :frowning:

That’s mainly due to the import from the old site. I have a set of tasks already for tidying it up, pretty much along the lines of what you proposed (there will be a group-<groupname> folder for the images of every group; I created group-lote3 already). However, that mode is not supported by default (instead, there’s one user-<username> folder per user, already). So for now, normal users will use the user-<username> folders, and admins can use the group-<groupname> folders if existing, until somebody has 2-3 days to reorganize it tidily and migrate the old image locations …

Header bar questions …

“get rid of the header bar – or rather replace it with a different one that uses the Edgeryders, the MT2019 and the unMonastery logos.”

There is no clean, minimally invasive way to get this done (that is, no clean way with CSS, and I resist applying more dirty hacks to the site as it just creates problem for the future …). Is this really needed? The problem with the LOTE3 minisite is, it’s a bad thing in terms of user navigation: users arrive at some site that does not share anything (no menu, no header) except the domain with the rest of the Edgeryders site, yet are told in the process to register at the Edgeryders site. And from there they will not have a link back to the minisite … . That’s confusing.

I’d propose to put the edgeryders.eu mainsite menu back in the minisite, which means that the minisite menu will be seen as a second-level menu bar. Then link the LOTE3 main menu item to the minisite instead of the “Making LOTE3” group, and add a menu item for “Making LOTE3” to the minisite’s second level menu bar. While LOTE3 is upcoming, we may replace the main site logo with one that has the unMonastery and Matera logos added, or a hint to LOTE3 or sth. …

The other clean alternative is to use the virtual_site or sites module to provide a second, completely distinct website (own menu, own header, own logo …) within the same Drupal installation that we have. But to avoid the above mentioned confusion, we would have to provide it from a subdomain like lote3.edgeryders.eu. However, this tears apart our web presence in a ĺogical sense as there’s no clear navigation back and forth between the two, so I’d argue against it.

Redirect?

“(optional) redirect http://lote.unmonastery.eu to edgeryders.eu/lote3

I suppose you mean a redirect from lote.edgeryders.eu, as the unmonastery.eu domain is managed by uM folks? We could do that redirect from lote.edgeryders.eu, but I propose we have to decide first what the minisite is to become, as per the discussion above: something living at lote3.edgeryders.eu directly (no forwarder needed, then) or a normal group-style part of the site at edgeryders.eu/lote3 (no forwarder needed either, but could be done).

Logical separation => good

Matthias, here’s the thing:

  • the main ER website is big and sprawling. It has to be that way, because it's a workspace for many different things, has lots of features and people actually use it. This makes it almost impossible for a newcomer to figure out what's what.
  • #LOTE is going to attract a lot of newcomers. So we felt the need for a simple, read-only website to serve as a point of entry. We did the same for LOTE1 and LOTE2. In other words, logical separation is what we are looking for here.
  • links bringing the visitor from the minisite to the main site are strategically placed across the former. The idea is: here is some curated information. If, after perusing it, you decide you want in, we'll move you to the workspace, which is a read-and-write website. We also provide human interfaces to guide your transition.
  • the way I would solve the problem of linking back from the minisite to the main site is as follows. We now have a LOTE3 item menu, that leads to the workspace. I would change that menu item so that it leads to the minisite instead. We can also change the alt text so that mouseover gives you a hint: "All about the \#LOTE event", or something like that.
  • we are already using a separate third-level domain (lote.edgeryders.eu) for the existing Wordpress minisite

So, I guess: my preference would be for a separate minisite, using our existing Drupal install with the Virtual Site or Sites module and its own third-level domain. This may also help tomorrow’s corporate website, which is my next project: as we talk to prospective customers, it’s clear that we need somewhere to catch them. Drupal Commons is a great workspace, as it allows for different groups to work on separate things while still staying within sight of each other: but it’s clear we need tidier corners of the website for cases in which we need to present editorialized information to people who will read or look, but not necessarily participate.

If this is technically not possible or exceedingly hard, the next best is to do as you say: we keep the top-level menu and use the LOTE minisite menu as a second-level one.

Tech perspective

Phew. Thought about it and it still seems not recommendable to me. Ok, I guess we should find a final decision on this in the upcoming Edgeryders directors call. Have re-enabled the first-level menu for now (meaning “second best solution” except I did not do the menu changes).

Some more reasons for not liking separate minisites:

  • Basically I'm not up for ad-hoc website mods or pieces of throw-away-after-use software on this site because I have no time for the medium-term implications of this. From a tech perspective, what I am working towards medium-term is a site structure that is adaptable by self service for all the needs we have, like more LOTEs, pages about the company etc.. A low-maintenance site. High-maintenance sites tend to be of mediocre quality: if admins are busy with doing DNS changes and template copying for new minisites, new custom views for new LOTEs etc., we'll not find time for the many UX issues and bugs, including these nasty error messages when saving content, and being brought to the wrong page after saving, and all the rest like these.
  • While I don't care much what the exact basic structure of the site is (using OG groups as projects, or as groups, or as overlapping temporary teams for any purpose?), there should be a basic structure that we should agree on. Then, whenever designing an addition to the site, people have to think about how to neatly fit it into the existing basic structure. That's the same as when adding features to software – in the world of software, doing otherwise leads to bloatware or even "entropy death". Due to many collaborators, we have a good amount of entropy already that we have to consolidate some time (like the sidebar-style second-level menu introduced on the About pages versus the horizontal second-level menus on the Lote3 resp. Making Lote 3 groups, of which one is in black and one in green :D).
  • The lote.edgeryders.eu WordPress site was never intended to become the LOTE3 entry point. I set it up because Nadia wanted to look up / migrate some old content from there, then started to reuse it for the prior minisite version as I had no time to do it in Drupal back then. It is a subdomain simply because we only have one domain and that's the easiest way to make a separate software installation accessible.
  • If the Edgeryders site as a whole is too difficult to understand for newcomers, we should work on that (we definitely should – several people mentioned how they had initially no idea how this site works and how to contribute ...). Having a "sheltered area" like a minisite just hides the problem ... . Note how the "Making LOTE3" group was already meant to replace the prior WordPress minisite, having the hint to registration and the special layout etc.. Until it got too complex and again we needed a simpler site. I guess this pattern will repeat until we learn to manage and reduce the complexity on spot instead of building a simpler version around it :-)

Read-only vs. read-and-write

Respectfully disagree. The Making Lote group was conceived as a workspace. It is messy as all workspaces are, and for the same reason: that people are authorized – and indeed encouraged – to edit them, add content, modify etc. We knew beforehands we would need a read-only space for communication purposes (just as we had one for LOTE1 and another for LOTE2); but, at the time of setting up the workspace, we did not have the content, and we opted to start growing the host of LOTE3 participants organically from the volunteers. I was one of the people who pushed for this solution. So far it appears to be working.

We will always have the need for read-only. Because:

  1. some people we interact with will never be community members: potential clients and other stakeholders, for example. They are just going to take 5 mins, tops, to find out about us as they ponder whether we are worth getting in touch with. The interaction will then continue (or not) via email, or maybe in person.
  2. others might become community members, but they need information to make that decision. During ER1 this was not so much of an issue, because we had the Council of Europe study creating content all the time: we would push that content out, and people would find themselves on the main site without perceiving (or indeed needing to perceive) its overall architecture. If they were stimulated enough, they would leave a comment and start this way to engage with us. From there, it would be relatively simple, as we had just one overarching purpose for the site. Now, it's not so simple anymore.

You may object that my point 2 only says that we should sit down and fix the main site’s overall structure. I would very much like that, but I admit I have no idea how to do it. It seems to me that there is a fundamental conflict between readability (that calls for editorialized content/organization information and read-only) and actionability (that calls for messy UG content, customized organization information and read-and-write). This architecture problem might be too difficult for me to solve elegantly. So, either someone else cracks it or it’s down to unelegant hacks like minisites.

Ok, this discussion is quite well developed. I see that we are already at my second-most preferred solution. Let’s see what the others think.

…and we close it!

Update: [Nadia], who is the most neurotic of us on graphic design, can live with the two-levels menu. So, this stays. I am closing the task. My thanks.

BTW: I know drupal

In case it’s useful, I do Drupal stuff both for my day-job and my “hobby projects”.  If I can be useful (given these commitments) please let me know.

Yes :slight_smile:

It is super-useful, [JoeCorneli]. So far, the Drupal team consists mainly of [Matthias] and [Auli] on the coding side and me, [Noemi] and others on the admin interface side. Can I ask you to add yourself to the tech team group? Click on the “Subscribe to group” link.