cellear's picture

Hello, Backdrop community.  Back in my college days, I was heavily involved with a band called Dreamspeak.  I registered the domain dreamspeak.com in the late 90s, and for most of the time since then I've had a site available there -- more often than not, something I've been embarrassed about!  My first Drupal site, in 2008, was a version of the Dreamspeak site.  But it hasn't really changed in 10 years, and even its modest presence fell into disrepair.

Last year, I began to try to reimagine the site in Backdrop.  I created most of Dreamspeak's posters, so the first thing I did was create what I think is an entertaining splash page referencing our current Zoom culture.  (I know splash pages have been out of vogue for decades now, but poster art was one of the main things I did for the band, so I thought it was appropriate here.)  I put together some thoughts, gathered some content, but then life got in the way enough to keep it on the back-burner for a long time...until now.   Coming into 2022 as a new empty-nester, I finally buckled down this month and did enough work on it that I'm willing to release it.  So I've set a date, to keep the focus and pressure on, and that date is Feb 4 -- next Friday.

Here's a link to the main online dev site: http://dev.dreamspeak.com/

(I don't mind it being out there, it's already far less embarrassing than the current www.dreamspeak.com site)

Here's some screen caps of the dev site as of tonight, January 29, both to preserve the history a little, and so you don't have to click through to see it -- especially if you're not on a desktop, since the mobile presentation is still pretty sketchy.


Anyway, here are some of the things I'd look for opinions about:

  1. Information architecture.  I've built up the site's structure mostly around two kinds of elements.  First, there are the band members themselves.  Dreamspeak broke up over 30 years ago, and each of the members have continued on.  Ultimately, I see that as being the source for most new content that comes into the site.
  2. Front-end work, especially responsive behavior.  I've kept the mobile behavior well in mind throughout the design of the site, but I definitely did not design it mobile first, both for practical reasons and because of the nature of the site.  Many of the visuals are best experienced on a large screen, and I wanted to optimize that experience, while still making sure the features that work well on a small device are fully functional.  (In this case, that means making sure the extensive audio -- dozens of hours, probably 200-300 songs -- that's available on the site function well.
  3. How to best add crowd-sourcing features.  I'm hoping that members of the community will help to contribute content to the site, potentially a great deal of it.  I want to make that possible, while at the some time not wanting to become a home for spammers and other scammers.

I'll dive deeper into these and other issues in this thread's comments, tomorrow and in the following days.


cellear's picture

I promised some details; here we go.

Dreamspeak, like other performing groups, presents some interesting information architecture challenges.

  • Within the five years that the band was together, at any one time there were between four and seven members.  Three players were in the band the entire time, and the other four at various times.
  • Four (mostly) non-performing people had significant enough roles with the band to be considered bandmembers.
  • All of the performers wrote songs -- there are a lot of them!  Dreamspeak played from a repertoire of around 100 original songs, and maybe 50 or so covers.  Live shows were probably 80%+ originals.  The selection of songs, the order, and many details of the performances changed dramatically night to night.  There was usually no pre-planned setlist, and spontaneity, originality, and passion (rather than lack of flaws or flash) were the goals of most performances.
  • Perhaps because the performances varied so much, many of them were recorded.  Also fans kept track of songs that would get played, and shared setlists with each other.
  • Many concerts were advertised with posters that would be hung up on the street.  (I made many of those, perhaps most.)
  • Lots of photo were taken, both on and off stage. 
  • A few videos were captured.  (Videos were rare in pre-iPhone days!)
  • The band members did interesting things outside of, before, and after Dreamspeak, which are worth mentioning.

With this in mind, I built the architecture around bandmembers and gigs -- all the other objects relate to both.  A "gig" is any kind of thing that has a date associated with it -- mostly concerts, but could include other things, like recording sessions.

Here's the architecture, I came up with, but I would love to hear suggestions, criticisms, and ideas.  I made some choices I'm unsure about :)

Content types:

  • bio
  • photo pile
  • artwork (mostly posters)
  • video
  • website


  • Bandmember
  • gig
  • art type
  • photo category
  • person
  • song

The controversial ones are "gig" and "bandmember."  Gig has lots of fields; I'm using it like a content type. Some make a lot of sense to me -- date, location, venue name and image.  But additionally I've added a few fields that feel like they could and perhaps should be content types instead:

  • Gig photos -- a multi-valued image field to store photos of the show
  • iFrame (could use a better name) -- this embedded HTML stores the 
  • band member at gig -- term reference to bandmember terms, so we can tell who was there.  (It could use a better name)

Bandmember is controversial for the opposite reason!  There's already a "bio" content type and a "person" vocabulary -- do I actually need it, or should I just reference the bio nodes of the relevant bandmembers?  I would take advice.



@cellear - It's hard to give advice on this without chatting, because I'm not quite sure why you made the decisions you did. 

I'm certainly confused about the "Bandmember" vocabulary, but I suppose I can imagine that it might be helpful. Seems like you can do node reference just as easily.

Also, it seems like I would probably have made GIG a content types, but I'm not sure that there is anything wrong with having it as a vocabulary either. 

I'd be interested in a general discussion about how folks decide if a type of content (like these examples) should be a content type or a vocabulary.

Here is my initial answer, without giving this too much thought. 

VOCABULARY is best used for terms or content that is primarily used to organize other content. 

CONTENT TYPE is for anything that stands on it's own as something valuable that site visitors might be interested in by itself. 

While GIGS might be something used to organize the music and band members, I think that in your case gigs are important pieces of content on their own. 

Site visitors might be interested in commenting on a gig, telling their own story. It doesn't seem like users would want to comment on a vocabulary term. 

By this same argument, maybe SONG should be a content type as well. I can imagine artwork, covers, history, or stories being associated with individuals songs. Songs are much more than a vocabulary used to organize other content. 

Photo category and art type are excellent examples of vocabularies.

So these are the thoughts that spring to my mind as I think about your questions.

cellear's picture

Isn't it easier to tie things together with taxonomy terms than between content types?

Maybe I'll try to refactor it; I didn't think I could use nodes that way.

I THINK that you will be able to do everything you want with a node reference field. 

cellear's picture

@stpaultim This may sound naive, but...how do I make node reference fields?  It doesn't show up as an available field type, and I don't see a module I can enable to provide it.  I didn't even find it in project browser.  How do I make one?

Is there a way to achieve my desired reference structure without it?  I'm struggling a little discerning the difference between what's possible and what's best.

I agree with Tim that most things would be content types.  When I worked in the police, all content was around the POLE model - Person, Object, Location, Event and everything else was the metadata/vocabulary.  I wouldn't use this as a hard and fast rule outside the police; I think location is the key one that could go either way in your case, depending on how significant the venue of the gigs is and whether you want to map them further down the line.

Only art type and photo category look like vocab out of that list, but I guess you might also have some fields where the options could benefit from being a vocab.

Your solution made sense, because Backdrop Core comes with a term reference field, but NOT a node reference field. Which is why for the last 6 years, we've been discussing the idea of adding a full featured reference module to core.


The two contenders are:

Until recently, Reference was the module most likely to get into core (eventually), but recently Entity Reference is surging in popularity. 

Either of these modules allows for node references, which work very much like term references and will suit your use case. 


The reference module providers a reference field with these options.

Here is a screen shot from Entity Reference, settings for the Entity Reference field.

cellear's picture

Awesome!  I’ll take both for a spin and see what they each “feel” like to me. 

cellear's picture

I think I’m starting to wrap my head around a more reasonable approach.  I think I can factor recordings and photos out of the “gig” term and make them content types, with a term reference to gig.  That would let me create the same views I’m using now.  What’s less clear is whether I can turn gig into a content type itself, without installing another module to let me do node references.

I could potentially have a pattern that has a node and a term for each gig, but that doesn’t seem DRY enough.  I need to tag relevant content with a gig, so don’t a need a vocabulary to do that?

I'm struggling a little discerning the difference between what's possible and what's best.

Using taxonomy references is easy, because it's in core and I don't think there is anything wrong with it.  However, I believe that for a site like yours, the data module is just complex enough that it justifies an advanced "reference" module. By default, I would include one of the two contrib reference modules mentioned above in most new projects, if I expect to use references at all. 

Right now, I'm simply not sure which one to use - because one or the other is likely to get into core at some point, but we haven't decided which one.

cellear's picture

For context, this is the layout it needs to fit into.  This is the “nest” layout, one for each band member.  (The naming is an inside joke, I may or may not continue with…)  Each of these is a view block for a different kind of content that is tagged with the band member.

You can see an example here: http://dev.dreamspeak.com/nest/psychner/bio


cellear's picture

So after some experiments in search of a more "normal" approach tonight, I'm back to thinking that my seemingly-wacky use of terms as a fundamental building block instead of nodes is the only way to get the behavior I'm after without either A) a node reference module or B) tying together items in a custom layout with a taxonomy term in a way that i haven't been able to get working.

Since the site is working well enough in its current form, and I'm planning to launch it on Friday, I'm (probably) not going to try to refactor it ahead of launch.  Instead, I'll try to fix the visual bugs and some of the really obvious content mistakes, launch it, and try to get some help from the community to add in content.  After it's up, I'll work on the content model and try to make it a little less kludgy.

I've got some thought to tie a bunch of nodes together based on a common term by using a view that only displays one result.  Are "singleton Views" a pattern?  (In Drupal I usually did this kind of thing with Panels, which is why I think it can be accomplished with Layouts, but I've had difficulty getting that to work.)

It's possible that I might be able to just create a "gig" content type with all the same fields as my current "gig" vocabulary and everything I've done so far will still work, but I feel like I'm forgetting something.  I'll try that (probably after initial launch) and see if it just works -- I might be confusing myself for no particular reason.