[buddypress-trac] [BuddyPress] #4952: New template pack for BuddyPress

[buddypress-trac]

#4952: New template pack for BuddyPress
-------------------------+------------------
 Reporter:  karmatosed   |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  1.8
Component:  UX/UI        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------

Comment (by sooskriszta):

 @karmatosed Thank you for the quick, patient and detailed response and
 explanation.

 I can't code PHP, only a little bit of CSS...so never figured I could
 possibly participate in BuddyPress development. Till about a decade or so,
 I did head user-experience/UI for a large portal (50+ million users).
 Frankly, can't say I have kept up with every development in the field
 since then, but can try to contribute some thinking. And as long as
 experts like you are at hand to guide me down the right paths, hopefully
 something positive can come out of it.

 I'll try to join the next devchat.

 I'm not sure I understand the difference between theme and template. As I
 said in #4124 my understanding is based more or less on what bbPress does.
 It seems to me that a template for a particular post type is essentially
 the structure that's inserted into the main content area, which is wrapped
 around by whatever elements the theme provides. Is that not correct?

 Now, to the specifics discussed:

 '''Member directory'''

 Maybe I am missing something rather obvious here, but I don't see a ton of
 scripting (I assume by scripting you mean JavaScript) going into the photo
 wall. The job can be done primarily via CSS (and HTML), and I am happy to
 chip in there.

 Of course, I suppose it depends on what's being attempted. I haven't seen
 Turtleshell, but I suspect it was more elaborate and complex if there was
 a ton of trouble getting it right.

 The biggest challenge, though, is not the visual structure, but rather the
 information. At the moment, it is so sparse as to be practically useless.

 The photo wall structure is the "dominant strategy" in game theory terms.
 Let's assume for the moment, that we do the hover overlay via JS (though
 we don't have to). Then the 7% of folks who don't have JS activated don't
 lose anything compared to current layout. And the 93% who have JS
 activated actually could possibly gain a lot more valuable info.

 About the usability-related discussion, let me preface with this:

 It is a fallacy that all functionality should always be out in the open.
 "Discovery" plays a very important part in usability and loyalty. Info
 that's not "always" required can judiciously be hidden in such a way that
 it is easily discoverable.

 Discovery bring a certain joy with it, which is lost if everything is just
 upfront (not to mention clutter for folks when they don't need the
 particular feature...no point trying to make everyone use everything).

 We actually did (many years ago) several tests involving a total of 12000+
 users on "knowing to hover" (it was a part of a bigger test suite, not
 simply about hovering).

 What we found was people will hover on photographs, irrespective. Most
 will try to click on photos too...doesn't matter if the photo is linked or
 not. But I digress...

 So, folks will hover on photos (not so much on text or links). And even if
 they don't immediately hover, they will eventually (within 10 secs). So
 that is a non issue.

 I think the bigger issue with hovering is folks who are visiting via their
 phones and touchscreen tablets. And they lose on some of the experience
 that the Desktop-using folks get, but they aren't losing anything compared
 to what they will have in non photo wall structure. Additionally, with the
 new developments, I suspect it won't be long before touchscreen UI would
 be able to translate hover actions, if it hasn't learned that already.

 Icons and button provide salience and visual aesthetic than links. Using
 '''well-designed''' graphic icons should definitely be a part of our
 toolkit. I totally get the "open to interpretation" aspect, and hence the
 emphasis on well-designed. Plus, I always, always use tooltips (title
 tag). The idea is that it's obvious that many first time visitors won't
 know exactly what each icon/button is for. But the only have to
 hover/click once to dicover/learn.

 Specifically as to the "green light", it is fairly obvious to many folks
 who participate in online communities (or IM). If it's not obvious, you
 can hover and see tooltip "online". If you don't hover, it doesn't matter.
 Not everyone HAS TO KNOW what this little light means. That being said, it
 was an off-the-cuff idea. I don't think it's a great one. Probably needs
 further developing before we even consider it.

 '''Group directory'''
 I appreciate your instinct visually differentiate pages that have
 different content types. In case we go for "photo wall" for member
 directory, the visual differences between the two would be quite stark.

 The only reason I suggested 2-column layout is that I feel that's more
 efficient as far as usage of screen real-estate is concerned. In the wild,
 it seems that most groups don't have any description, or at most a very
 sparse description. Then it's just lots of whitespace (which is good and
 important to have sometimes, but I think there's a bit too much here)

 Thanks for considering the inclusion of Group "profile" image here.

 '''Activity profile'''
 Okay, so to be a bit clearer that I was last time - I assume this is the
 member profile page...in that it provides the profile "skeleton" and
 individual tab content opens up where we see the "activity". Did I get it?

 Member display name, I feel is absolutely essential as BuddyPress is
 increasingly being adopted by non-developer and non-technical audience
 (who don't use Twitter and won't know what @username is for) and
 communities that might not even activate activity. Then display name would
 be how they identify folks (just like in real life). Thanks for
 considering bringing it back.

 What would be H1 on this page if not the member name? (Same goes for the
 title tag in head). H1 is pretty important for SEO. Imagine - someone
 searches for your name in Google, and the BuddyPress community shows up in
 top results. Isn't that what we are/should be aiming for?

 You are probably right about previews being widget territory. Would be
 nice to have 2 widget areas - one between member name and activity/tab-
 content, and another below the tabs in left column. I would hope, though,
 that the core team supply "preview" widgets in the "box".

 I understand the point about deadlines, targets and timescales. And I feel
 that if we agree in principle on some things, then they don't ALL need to
 go into one release. Some can punted off so that more detailed work can be
 done on them.

 Thanks again for being so open and patient.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4952#comment:17>
BuddyPress <http://buddypress.org/>
BuddyPress