#4952 closed enhancement (fixed)
New template pack for BuddyPress
Reported by: | karmatosed | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Core | Keywords: | |
Cc: | karmatosed@…, trisha@…, mercijavier@…, rachel@… |
Description
This was talked about in the 1.8 scope meeting and I'm going to summarise the suggestions as best I can here.
The proposal is to create a new template pack for all the major templates for BuddyPress. As to what extent this is, it would be done by a review and wireframe of each major area.
A new template pack can draw on the work done as part of Turtleshell (http://turtleshellp2.wordpress.com). It shouldn't be rigid in taking every template as Turtleshell does though - there should be a review process of each template.
The proposed format for this would be one that had some strict time scales and cut off points.
If there is a 6 week development time to be set on this then the following would be a suggested format:
- An exploration week with wireframe reviews and submissions of new directions
- A week to refine and rework based on opinions
(Review if on track or go for 1.9 and have more refine time could be made at this point)
- Development for 2 weeks
(Review if on track or go for 1.9 and have more refine time could be made at this point)
Ideally a ticket per area would be created so each can be discussed and refined.
Depending on the number of people available this could be done one by one or in teams. Each time a template is done a UI review needs to happen.
- Development either ends in 3-4 weeks to keep on track for release or carries on into 1.9
The production of this would be done as a plugin similar to Turtleshell and a lot of that can be reused structure wise (even templates if those are the ones agreed on). Hopefully this will mean it can be early tested and free from the cycle to then be brought in when ready.
It's also a chance to get get accessibility into the UI and also user tests on the new templates.
Attachments (13)
Change History (117)
#3
follow-up:
↓ 4
@
12 years ago
I've collected all the wireframes from the work done in Turtleshell and the threads around wireframe exploration back then.
You can find them here: http://drp.mk/ggy
I think coming up with an attack plan list is a good idea. The way I see it the main hit pages are:
- Member directory
- Group directory
- Blog directory
- Activity stream
- Member profile
- Group profile
- Messaging
The secondary hits are:
- Settings
- Profile fields
This week's plan is to work on wireframes. Anyone is welcome to also join this process. We have some good starting points with these but lets be open to anything new we may want to do. I'm going to work on some new wireframes myself and add them here. I'd encourage anyone else to - they should be just wireframes though and even hand drawn works. The idea is a low cost wireframe.
I suggest we collect them all here and we can then review and add to a board (unless objections I think Dropmark works well for this) then review and see what we have.
Next week the plan would be to refine, get feedback and work towards a final set.
#4
in reply to:
↑ 3
@
12 years ago
I really like what we have there personally i do have a few thoughts maybe some of these might not really count because these are wireframes or whatever but anyway i will try to take stab or two this weekend and see if i can add any other ideas.
•1 i think there are too many lines and boxes on these layouts in general (maybe a wireframe thing) :)
•2 on the messages screen there is mention of hover effects i think it would be advisable to think of touch interactivity as a primary concern. also seems this is the only place we are using color which seems a bit odd to me. i think i sorta prefer the revised message wireframe myself.
•3 on the revised group wireframe i could be crazy but i think we have an extra box in there? (picture attached)
thanks for all your hard work karamtosed!
#5
@
12 years ago
@ubernaut : no problem, thank you for taking a look. A few people though worked on these wireframes when they first came out so everyone gets the credit for those. Whilst we do have them, I'm keen we don't see these as final though as said. They are just where we got in the last look. I personally plan to explore other layouts and encourage others to. I'll try and respond to your points and hopefully clarify some things:
- These are wireframes so yes.. kind of liney :) However, a lot of things may change and can change once we're working on them.
- Colour was merely there as a suggestion of 'states'. Personally I'm not sure any wireframe is there yet though so would be keen to explore other ways.
- That was a menu box. Again it's all up in the air and open for exploration.
I'm looking forward to what you and others throw into the mix - going to be cool to see ideas.
#7
@
12 years ago
I've explored a few areas this week focusing on the main ones listed. I took some inspiration
I've uploaded some ideas for activity, group profile, group directory, member directory and messages.
http://buddypress.trac.wordpress.org/attachment/ticket/4952/messages.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/memberdirectory.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/groupsdirectory.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/groupprofile.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/activityprofile.png
(note : I've not done the blogs directory yet for a reason. I would like to do what Turtleshell does and have a summary view of all activity in blogs for this section but we may need a directory list also. As a result I think discussing this apart would be good so lets put to one side for now).
At this stage, I am just putting them up as ideas - probably best until we get everyone's submissions (a few people mentioned would try and get some in this week) before we see what we have and look to what we can refine and discuss.
#8
follow-up:
↓ 10
@
12 years ago
and a lot of that can be reused structure wise (even templates if those are the ones agreed on)
I was always of a mind that with template packs a eventual reality that this was the principle that could be followed.
Based on the given symbiosis between markup and CSS, with CSS able to add almost virtually any visual layout to the markup structure as was it's purpose we ought to essentially have one set of template files that tend to remain unchanged once they are worked out and then new packs can be rolled out with essentially the work being carried by CSS.
Structuring those templates regardless of what visual style we may decide on is certainly going to be an important next step.
#9
@
12 years ago
As the cut off time has been reached the following wireframes are going to be the ones worked on this week and refined.
http://buddypress.trac.wordpress.org/attachment/ticket/4952/messages.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/memberdirectory.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/groupsdirectory.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/groupprofile.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/activityprofile.png
If anyone has any comments, improvements, suggestions - please say them in this thread over this next week. If you'd like to propose refinements in the form of wireframes also please do that.
As of next wednesday we should be aiming to have a set we agree on them coding.
#10
in reply to:
↑ 8
@
12 years ago
Replying to hnla:
and a lot of that can be reused structure wise (even templates if those are the ones agreed on)
I was always of a mind that with template packs a eventual reality that this was the principle that could be followed.
Based on the given symbiosis between markup and CSS, with CSS able to add almost virtually any visual layout to the markup structure as was it's purpose we ought to essentially have one set of template files that tend to remain unchanged once they are worked out and then new packs can be rolled out with essentially the work being carried by CSS.
Structuring those templates regardless of what visual style we may decide on is certainly going to be an important next step.
@hnla I agree within reason. We're not creating a framework here, so I'd say we're not totally looking for something that can become anything. We are creating a solid base. We can't and shouldn't be making a framework / one layout that can become anything. We should be sensitive to providing a solid skeleton that can have a variety of changes (big difference).
This said the underneath skeleton will as a result of this process be reviewed.
#11
@
12 years ago
yeah ended up with about 25 minutes to revise at the end of the day yesterday so i knew that was a fool's errand. Anyway as i said before i like what we have already quite a bit so happy to work on revising will reply. Within the next week on my thoughts about the details of the existing mockups. Thanks again for all your help and hard work karmatosed!
#12
@
12 years ago
@karmatosed yep skeleton structure is exactly what I meant, there are elements that shouldn't change and classes/id's that must be observed, it's that and the attendant primary elements that represent the markup structure and which has no reason to change ( it can be extended from template to template pack if really required no reason it can't be )
Once a firm structure is in place ( much as we did with Status theme ) CSS is then able to do it's work CSS-P as was intended applying visual positioning and styling if a template pack in future needs or wants to modify things it's able to based of something well written.
#13
@
12 years ago
@karmatosed Wow! Seems a lot of thought and work has gone into these. Thanks!
I do have a bone or two to pick with the members directory, though.
The suggested format http://buddypress.trac.wordpress.org/attachment/ticket/4952/memberdirectory.png seems to be not very helpful and a grand waste of space.
There are 4 items per member:
- Profile photo thumbnail
- username
- time since last login (I assume that's what you mean by "Since logged in")
- "Add friend" button
From a user perspective, these bits of information are not very helpful (don't provide any good sense of the member), with the exception of the profile photo thumbnail (who cares if hnla was last logged in 5 mts ago, 4 hours ago or 2 days ago?). Unfortunately, because there's not much information in the box, so the thumbnail is kept small, in order to minimize real-estate waste.
So what would be good pieces of information? (things that would help the "average" user in understanding more about the members and making a "friending" or clicking decision)
Well, that depends! On the type of community. Hence #4126
But there are a couple of things that could be useful for *most* communities:
- larger profile photo
- name/screen-name instead of username
What I recommend is a format where there is a large (between 150px x 150px and 200px x 200px) profile picture. Display name is above the image, along with an "online now" indicator (small circle that turns green when online, grey when offline). Add friend/ Friend request button is below the photo. And any additional info/fields are overlayed on a semitransparent layer that appears on hover.
http://buddypress.trac.wordpress.org/attachment/ticket/4952/memberdirectory.jpg
http://buddypress.trac.wordpress.org/attachment/ticket/4952/memberdirectory-hover.jpg
This way, space is used quite efficiently. It is quite the trend, courtesy of Pinterest, myspace, Tumblr, Windows 8, etc. And because it doesn't have wide, rigid boxes, so it can easily be responsive.
#14
@
12 years ago
P.S. The "Add friend" button could be made smaller, using graphic icon instead of text and overlayed at bottom-right corner of the image...doesn't necessarily have to be placed below the image.
#15
@
12 years ago
Group directory
http://buddypress.trac.wordpress.org/attachment/ticket/4952/groupsdirectory.png
- Often groups have "profile" images too. Shouldn't we display them in the directory? I feel it could be a good thing to display the images. Reading is exhausting compared to well-chosen profile images.
- Also, why not make this 2-column like http://buddypress.trac.wordpress.org/attachment/ticket/4952/memberdirectory.png ?
Group profile
http://buddypress.trac.wordpress.org/attachment/ticket/4952/groupprofile.png
Maybe I am not seeing right, but it would seem to me that the most salient position on the page for the Join Group button would be adjacent to the Group name on top. Opinions?
Activity profile
http://buddypress.trac.wordpress.org/attachment/ticket/4952/activityprofile.png
I assume that this is really the member profile page.
Here's the beef:
- Why is there no display name on the page? Group profile very sensibly has the group name right up top in bold (H1) http://buddypress.trac.wordpress.org/attachment/ticket/4952/groupprofile.png so how come unlike every other social network, the member's name is just absent from the profile? I suggest we put the member name (display name) right on top as H1 just as group name is on group profile.
- The other thing is a bit broader: I would like to challenge the whole paradigm of "click on the relevant tab to see details". I feel it is much more sensible (and common) to show previews from each tab (groups, friends, photos...) on the main profile page itself. If someone wants more info they can click to see that tab. But just visiting the profile page should give the first-time visitor some sense of the member, and for that the activity feed by itself falls woefully short.
So I propose something like this: http://buddypress.trac.wordpress.org/attachment/ticket/4952/profilewithpreviews.jpg
#16
follow-up:
↓ 56
@
12 years ago
@sooskriszta: Thank you for your comments. Also, thank you for your wireframe contibutions. I'd encourage you to join the dev chats if you can to become part of the project. It would be great to bring you on board.
Let me first go over a few aims for this template pack as think this answers some of your suggestions. Then I'm going to try and deal with each.
- This is meant to not be a theme it's structure.
- To point 1, scripts and icons / images are going to be something we at least if we can want to avoid. We're still keeping to theme compatibility here.
- Groups and members are different directories so should look different.
- Whatever we do has to slot into any theme. That's one reason for a lot of choices in the wireframes.
Those points aside, here are my thoughts to your suggestions.
- Member directory:
I'm not against the photo wall as an option for members. However, it to be done right, elegantly and repsonsively needs to really have some scripting. If our goal is to be as light as possible adding scripting would go against this.
Oddly what you've got there is exactly what we had for Turtleshell. Unfortunately, it wasn't prefect at all. The issue is margins and formatting - it just looked clunky even with child selectors.
The format I have done is very like Metro style for the format and therefore does play to contact cards.
It's important we make sure information is right though so happy to consider other options there.
I don't feel a 'green light' works in this case. I understand what it means UI wise but I'm not sold a lot of users will just be lost as to what that means. We've got to aim for low and high end users in our UI. Same really applies to graphic icons. We're trying to not leave things open to interpretation or add graphics at this stage.
I feel a lot of your wireframes are more 'theme' which is fine but that's not really what we're aiming for.
The rollover requires a script and actually I did this for a client myself the other day. However, again the issue of 'do we roll javascript into the templating'. If we're going into 'any theme' is this a good idea? I'm airing on a no when we can do so much cool stuff just with CSS.
Another issue with hover is people 'knowing to hover'. If you have the right user base this isn't an issue but perhaps when we're considering a larger umbrella base it would be.
- Group directory:
I've had for a while strong feelings this should no matter what else be different from the members. It's different content. I'm keen on one being 2 column and 1 no column like the UI suggested for those reasons.
It's been raised about having an image so that's definetly something needs to be considered to roll in.
- Group profile:
I actually feel that the position of the join button is right where it is. I'm grouping actions in that UI so it fits there.
- Activity profile:
Yes and no it's 'really member profile'. It's showing activity on a profile so works to cover both UI.
There is no display name as the username is there. It could be added in again if we decide it needs to be. I'm not sold it's an h1 though - never have been on any of those profile names.
Showing previews feels like widget territory there if anything. We can though add a widget area there. So that's fine to consider.
Actionables I'm happy to bring in right now to the wireframes and will are the following:
- Add username and full name to member profile
- Add image to group profile
- Note that the menu will have a widget area after on profile so users can customise
I'll leave others to join the conversation and get your responses also to the above things before we move on anything else.
Our deadline for wireframes was yesterday but as you may not have known this, I am happy to allow yours to be considered. I'm not totally sold on rethinking everything though as would throw us off schedule. Don't meant to be strict about deadlines but we're trying to keep to a timescale.
That all said, I am hugely grateful for your contributions and look forward to you getting involved in this.
#17
@
12 years ago
@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/usability 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.
#18
follow-up:
↓ 37
@
12 years ago
@sooskrista: happy to respond.
Just a bit of a point though. Not every idea will get accepted and I hope this is understood. It's not a case of agreeing and punting into phases really. The idea is we're creating a template pack for this release. There has to be a cut off point. If other template packs happen then ideas will be opened up again.
If an idea doesn't get in you are welcome to try out concepts in themes or plugins (depending on what). I'd highly recommend that as a way of showing / prooving concepts. We can even look at some point to merge things like that if enough people think it's a good idea. However, there is no guarrentee.
You certainly don't need to code PHP to help with this, however for templates you would need to code html5 and CSS3. You would need to also be aware of responsive layouts. If this isn't your skillset though, eyes are welcome on work when needed and testing is always very welcome.
I look forward to seeing you at the next dev chat.
As explained in the ticket description. This is a new template pack - this will be the content output in by BuddyPress. This is designed to go into any theme. It shouldn't cause scripting issues, restrictions or weight as a result. A few things you're suggesting go against this.
I really do encourage you to download what has been done so far for Turtleshell and look as this puts a lot of what is being said in this ticket by people into context.
http://turtleshellp2.wordpress.com
https://github.com/paulgibbs/turtleshell
I will respond to a few of your comments with my feelings though.
- Member directory
I'm not sure you quite understand the issue which is variable height - I never said it was impossible as there are selectors.
When you say 'not seeing a ton' in reference to scripting, this means some. This is a point I made earlier. It would be a goal to not have any theme side javascript at least for the layout. If we add to it then we can, but the aim is a pure CSS layout first. You can't say 'what height' or set a height as this needs to be responsive and adapt if no information is given. That aside. I'm really not sold on this as said. Let me cover some points why and then lets get other's opinions. I would need a cut off to this though as it's quite a change. I'm keen to decide based on opinions on this ticket tomorrow evening.
Photo wall I'm not sure I'd agree is the dominant strategy in game theory terms (game theory is one of my pet subjects as well :)). However, that's a matter of opinion and interpretation - we all have our research and thoughts :) That's probably another debate for another day. It does raise a good point though. We're not designing just for a social network. BuddyPress powers a range of communities, some may be predominantly social networks, others are not. That's a very important thing to remember when proposing a UI. You could be proposing something to be used by a cribbage club for retired people, a football club, a school and a support group for an illness. You never know.
I can't agree that 'knowing to hover' works across user types or devices (without scripting). We have to appeal to anyone and any device. After all we're putting this into any theme.
If you are saying the cards should have more information and we don't hover.. we can't really have this photo idea anyway. The card idea seems a good middle ground.
I am more than happy to consider more information on the contact cards, but I really feel the photo wall with hovers isn't going to work for this template. I would be happy to bring that more information in though - this does make the cards more relevant and you don't need hovering.
The way things are working though is we're getting people's opinions. So, if others agree to explore it we can. If they don't, we will probably not explore that for the templates. I'll wait a few days to gain opinions before a decision.
Icons and buttons I am against until we at least review things. If we did include icons I'd be against them being images anyway and want an icon font. There is a valid argument that all default icons used on the front now could either go or be replaced by an icon font. That however, is probably another debate for another day.
The green light I'm voting against (other voices may vote for) as again it makes no visual sense to all users. It also may work in IM but on a community some may even not want to be shown online like that. I can see a tentative reason for it on profiles or on friend lists. I'd much rather see it in action as a plugin though. It's not really something to consider for the templates now. If you want to explore as a plugin like the UI refresh has been done that would rock and be a great proof of concept.
- Group directory
I'm rather against this being 2 columns and real estate is something we can only guess at (remember we're going for this fititng into 'any' theme).
- Activity profile
I think you'd get a few people arguing that h1 shouldn't be used like that for SEO but that's another debate and not one I'm joining in :) Not everyone also you should note, wants to be on Google like that.
I'm happy to do one widget area for now, lets review once it's built.
Actionables I'm happy about on top of ones outlined:
- Extra information on the members 'card'.
- Adding the user name but not as a h1 - will consider this in templates to be other headers and get more opinions than those expressed so far in this ticket.
I think we've included a lot of new things, so lets see what people think and take from there. I do have to give a cut off though for any experiements, or discussion. The revised wireframes are due on Tuesday midnight and I am myself travelling on Monday through to Wednesday evening so may not get a chance to review any changes.
#19
@
12 years ago
Not every idea will get accepted and I hope this is understood.
Of course. If I seem to push back on some things, it's just to have a thorough discussion on it. I also understand that when running to meet deadlines, there may not be time for detailed discussions either.
Thanks for picking up some of the items suggested. I'm particularly happy about more info on cards.
Also, thanks for your recommendations about how to get more productively involved.
#20
@
12 years ago
I want to chime in here and say thanks for this very detailed discussion. I don't have time to comment this evening but will try and make time to put my thoughts here before you travel @karmatosed.
#21
@
12 years ago
@sooskriszta
The other thing is a bit broader: I would like to challenge the whole paradigm of "click on the relevant tab to see details". I feel it is much more sensible (and common) to show previews from each tab (groups, friends, photos...) on the main profile page itself. If someone wants more info they can click to see that tab. But just visiting the profile page should give the first-time visitor some sense of the member, and for that the activity feed by itself falls woefully short.
Just to clarify one point, and while the above idea might be a good one, it starts to fall under the remit of themeing, something that would require specific re-factoring or creating of functions to re-work how BP spits out data in relevant screens/actions. The template pack process is one of looking at how the handling and presentation of the default BP output is managed, so it's focussed on UI/UX for the default activate and go BP content rather than manipulating functions to present new data views.
However I'll also qualify that by wondering if templates packs presented - if they are - as plugins couldn't actually have the means to do some simple backend work from a functions file? but I'm idly musing there.
#22
@
12 years ago
i would vote for the idea of adding the display name to the profiles. Also on that note i would agree that for groups the name, avatar and join button should all be front row and center. i would vote strongly against any fundamental hover effects as they have no utility in a touch environment. somewhat ambivalent in regards to the green light. i am sort of wondering how these layouts would look in a one column setting (mobile) or is the plan to squish all this down on small screens? i do sort of agree with the general notion @sooskriszta is relating about sparse information one thing that has always sorta bugged me about the existing buddypress screens is all the empty space, seems like it could be used more efficiently. uploading my one column thing even though it not likely too relevant but just incase we want to pull any of the ideas i'm also happy to expand on it if that if it's interesting to anyone even if we aren't using it for anything other then comments or ideas.
#23
@
12 years ago
@ubernaut: I am going to have to be a little bit of a stickler here for the time frame. It was explained that radically different directions would have to be cut off if didn't come in before the time. Therefore, we can't consider those changes. I understand you're keen but we did discuss this previously and in the chat. I hope you understand.
A point on sparce information. I don't believe we should ever just fill something up for the sake. If this is felt when we're working on the templates we can refine.
I am going to take a bit of an executive decision here and hope that is ok. I'll bring in those things I said would to wireframes and also others discussions will be included but we won't be changing the layouts now. This needs to happen if we are to meet any deadlines. We need to get into prototype and not get into an endless cycle of revisions.
I am absolutely open to refining and exploring once we have at least some structure done. We're in danger of spinning wheels now though so this has to be cut off.
#24
@
12 years ago
@karmatosed what changes now? i said i was just attaching for reference since some of @sooskriszta 's comments were reminding me of my initial reasoning. Also you had mentioned possibly incorporating some of the ideas so i thought it made sense to attach, i realize we aren't going in that direction. :)
i'm with you in regards to getting some movement on the actual work, in regards to sparse information i'm not suggesting that we fill for fill's sake I'm merely agreeing with the sentiment that use of space is not very efficient and could be better.
i am still really wondering about how these multi column layouts are going to work on small screens though.
#25
@
12 years ago
As I look over these I can't see anything I would particularly change given what we are trying to accomplish. I really like the changes I see, particularly in the messaging and profile areas. Coming from the angle of a BuddyPress Developer, my goal from here would be to make the markup adhere to standards and be as clean as possible. That way it would have the advantage of:
1) Being usable as well as attractive out of the box
2) It would be skinnable, ie a developer could apply basic css to it to change colors and simple styles.
3) Layout could be changed if desired (this one is bit of a stretch but not out of the realm of possibility by any means...I've done it to the default template)
You won't hear much more from me regarding usability, etc as my passion is more toward code and standards.
#26
@
12 years ago
@ubernaut in reference to the multicolumn layouts if I'm not mistaken (@karmatosed correct me if I'm wrong in this situation) they can be coded so that they will revert to a single column on a mobile device. I have thoughts on that but will save those for later.
#27
@
12 years ago
@ubernaut: Not sure ever mentioned to bring them in.. However, lets draw a line we need to get things focused and as all agree we can. The idea was always that the multi column would respond therefore this isn't an issue. It wouldn't be a multiple column on mobile and never was planned to be. You are bang on there with that being the intention @trishasalas :)
I'm also looking forward to developing these as I think a lot of the things can and should be explored in revisions/templates.
@trishasalas : Definitely agree on the standards. I'm going to work up some guidelines for templates and put them up for everyone to agree to who is writing them. We can then all be on the same page and refine these together. @hnla I hope you are also going to be a cornerstone for standards for this and help curate those guidelines?
#28
@
12 years ago
@karmatosed by standards I am referring to best practices for HTML/CSS as described by W3C. Will you have a set of standards for this template pack beyond that? (something I'm game to help @hnla with if desired)
#29
@
12 years ago
so yeah that's what i was thinking and that's why I'm wondering what that would actually look like seems to me a lot of the top of it is going to be eaten up by nav.
#30
@
12 years ago
@trishasalas: We'll be doing both web and WordPress coding standards. We also need things like naming conventions, guidelines to 'untheme'. I'll kick the ball off then we can see from there. We just all need to be on same 'field' whoever creates a template.
@ubernaut: I'm not worried but lets explore in template. Some things have to be done that way.
#31
@
12 years ago
@hnla I hope you are also going to be a cornerstone for standards for this and help curate those guidelines?
Absolutely; StandaNistaDivo!
@trisha yes standards with a capital 'S' but also we have to adhere to WP coding guidelines as well.
#32
@
12 years ago
I've uploaded 3 new versions to respond to the actionable things this week.
http://buddypress.trac.wordpress.org/attachment/ticket/4952/groupsdirectory.2.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/memberdirectory.2.png
http://buddypress.trac.wordpress.org/attachment/ticket/4952/activityprofile.2.png
I'm possibly not going to be in the meeting this week (depends if get home in time as travelling). What I will do though is on Thursday put up an action plan and we can then start with this. This coming week is the start of the building :)
#34
@
12 years ago
karmatosed I must say the screenshots looks great. Simple and uncluttered. Nothing much more to add, you've already ticked all the boxes
#35
follow-up:
↓ 38
@
11 years ago
finally got a chance to give a good hard look at these and i would have to conclude that i'm in love :P i would say that the vertical separators for various action buttons bother me a bit, wondering if horizontal space alone would be superior, maybe it's just a wireframe thing? anyway yes i really love the overall direction we going here. Let me know when we ready to start putting these together!
#36
@
11 years ago
I'm loving all these positive comments, major props to karmatosed. You are the right person for this job and it's apparent! Good work, I'm with everyone else...can't wait to get started :)
#37
in reply to:
↑ 18
@
11 years ago
Replying to karmatosed:
BuddyPress powers a range of communities, some may be predominantly social networks, others are not. That's a very important thing to remember when proposing a UI. You could be proposing something to be used by a cribbage club for retired people, a football club, a school and a support group for an illness. You never know.
Exactly! Hence, #4126 - the admin should decide for her own community what info goes on the cards.
I would be happy to bring that more information in though - this does make the cards more relevant and you don't need hovering.
Sorry, can't seem to locate this additional info in http://buddypress.trac.wordpress.org/attachment/ticket/4952/memberdirectory.2.png
- Activity profile
I'm happy to do one widget area for now, lets review once it's built.
Sorry, can't locate widget area on http://buddypress.trac.wordpress.org/attachment/ticket/4952/activityprofile.2.png Please can you help me find it?
Replying to ubernaut:
uploading my one column thing https://buddypress.trac.wordpress.org/attachment/ticket/4952/screens.jpg
Thanks for this. It's a good idea to have some clarity beforehand about what the template would look like on small screens than to merely say "it is responsive".
#38
in reply to:
↑ 35
@
11 years ago
Replying to ubernaut:
the vertical separators for various action buttons bother me a bit
Whatever do you mean? The pipe character | between the Reply, Favorite, Delete links?
Personally, I favor Gmail-style icons but since they go against our stylesheet/design-philosophy, and we are using links, separators (Yahoo! Mail circa-2000 style) do make sense.
#39
@
11 years ago
Apropos vertical separators:
@ubernaut
wondering if horizontal space alone would be superior
Technically no, not superior, accessibly flawed. This becomes not a question of visual styling but of wcag.
That set of action buttons is flawed in that it is a list or set of actions and would be correctly rendered as a 'list' Anchor elements are implicitly inline elements and intended to be rendered within inline data, rendering links bare and naked outside of that context requires that they have some form of symantic context, if and when they don't the requirement is that you must provide some means of establishing separation between those elements - this is not a visual requirement! - with those links rendered for example in a ul construct that requirement is negated and the developer is not required to establish separation as the ul li elements provide that, then we can choose to provide a visual cue in using vert separators as a visual enhancement rather than requirement which is the best of both worlds.
So one job that needs doing is the markup for those meta actions being re-written as a ul li construct.
How ever one huge flaw to that plan might be the fact that there is a dirty great do_action at the bottom of that containing div allowing developers to inject whatever they like which has the potential to break whatever markup is used here. Grabbing the contents of the do_action into an array and looping it into 'li' elements could work but still is flawed as we have no means of managing what may be in that array.
#40
@
11 years ago
@hnla gotcha, so is that flaw you mentioned even something to worry about then? i mean don't we need that do_action? and isn't it the dev's responsibility to ensure it works properly in their respective theme if we don't have the option of doing anything else with it? are there any other options of how to contain everything?
sorry i guess my generally lack of coding expertise may be hindering my understanding somewhat here.
#41
@
11 years ago
Hmmm we went off trac a bit here lets get a few things sorted and then we can hopefully move on. Sorry didn't respond for few days I've been away. I'll do my best to catch up now, thank you to all of you for your comments though - it's great to see the wireframes are for the majority something people think work.
- The divide is only there as an illustration of a link. As said before, this isn't a design as it's a wireframe. These are simply links. We aren't adding styling.
- Point 1. being said you can use :after CSS to show a divide if we want so not sure what the big issue is there.
- Cut off point is here. We're not doing anymore revisions.
- I'm going to try and be in today's meeting but still travelling and have conference brain so need to get back to things tomorrow. I will then post as said in earlier ticket about next steps.
- Lets try and keep this ticket focused on one thing at a time it's going to avoid confusion. Any things that need extra work can have tickets opened and debate done there. We need a bit of dividing up of things I think into sub tickets once we get to that point anyway.
- We won't be using icons @sooskriszta we've already discussed that. If we had anything graphic like that it should be an icon font and there are no plans for that.
@ubernaut: I'm sure we can find a way you can get involved. You don't have to know hooks like that so just don't worry about that for now.
@hnla: I feel you're overcomplicating things/going into other bits here that aren't these wireframes a bit to be honest here and my point 5 really needs to come into play so we can get things into focus. Hope that's cool just trying to keep things on track.
#42
@
11 years ago
@ubernaut the do_action is sadly not in the hands necessarily of the dev but of plugins etc and in that respect we don't know what may be pushed through which makes it hard to mark up those elements as they should as a list or even to add appropriate separators to what is hard coded.
@karmatosed sorry wasn't trying to take off track or overcomplicate the ticket is generic 'Template Packs' a remark was raised about separators so I responded to that as the issue is likely not one understood - yes :after could be used but still has the issue of what may be fed via the do_action but I'll not harp on about it :)
#44
@
11 years ago
Noting here that points raised by @sooskristza but already discussed are continued in another ticket here: https://buddypress.trac.wordpress.org/ticket/5011. The ticket was marked as duplicate due to same discussion and the wish to bring discussion into one area and focus people's efforts.
#45
@
11 years ago
Replying to #5011 karmatosed :
as of the dev meeting this week the templates will be ongoing until 1.9. So, therefore having things considered in their iteration is more appropriate.
So, milestone for this ticket is 1.9? What are our timelines with respect to this?
#46
follow-up:
↓ 50
@
11 years ago
@sooskrista: The plan of action is as follows (it's not changed from the start):
- Wireframes will be done
- Templates will be created
- Iterations will happen
During the iteration phase everyone is welcome to comment and discussions will happen. However, just because you request or comment doesn't mean it'll get in. The point is we discuss. Therefore, opening up a ticket just because your suggestions aren't being included doesn't progress things.
During this week's dev meeting we discussed the best reporting method and it was decided Github will be for issues and this ticket will become the umbrella ticket. This avoids '101 tickets' around the same thing.
Discussions are welcome on any dev blog post (I post every week), any dev update meeting, any Github issue and anything added in this ticket. That way we can all track and be informed.
As already stated several times you are more than welcome to be part of the UI process but we need to unite rather than fragment into different tickets.
There is no time limit / milestone for 1.9 - that's kind of the point. If we don't make 1.8 this moves to 1.9. We work on these templates and release when they are ready and formed. This is why the decision was taken to not rush to meet the 1.8 deadline. There is also no agreement another template pack will happen - so assuming that isn't right at this point until we've done this one.
#47
@
11 years ago
ok sorry just want to make I'm following here, does this mean that we are no longer considering the wireframes basically final?
#48
@
11 years ago
@ubernaut: They are final in sense of structure we're making up. We are now making templates which means we will iterate. The things @sooskrista was suggesting were not new layouts but additions and variations we have already discussed in this ticket.
#50
in reply to:
↑ 46
@
11 years ago
As suggested, bringing the discussion back here. For completeness, quoting #5011 below.
SOME, though not all, of these items have been mentioned here before. Now that this is no longer inextricably linked to 1.8, hopefully we can have a more complete discussion that goes beyond "no time for this" and "I'm doing it this way"
I should note that not all the suggested changes are purely "template" based - some involve functionality for which there are existing tickets.
(P.S. Should milestone for this ticket be changed to 1.9?)
Quoting from #5011
Group Directory
https://buddypress.trac.wordpress.org/attachment/ticket/5011/groupsdirectory-1.9.png
Number of member and whether Open/Closed? is moved above group description. The key information should be easily scannable i.e. easily grasped in one glance. That's what this visual promotion of number of members is designed to do.
The "grey" Joing Group button indicates that the user is already a member of this group. In reality, instead of a greyed out button, user should really see the text to the effect "You are already a member of this group"
Group Profile
https://buddypress.trac.wordpress.org/attachment/ticket/5011/groupprofile-1.9.png
Primarily 3 changes:
- @grouphandle below Group Name - dependency #3673
- Move "Join Group" button to top right. This is most salient place on the screen. Also, on directory pages, that's where the button is placed.
- Addition of 2 widget areas (content top and left column). Like all widget areas in WordPress, if there is no content in widget areas, they collapse.
Member Directory
https://buddypress.trac.wordpress.org/attachment/ticket/5011/memberdirectory-1.9.png
Member directory features so called "cards" format.
There are 3 changes from #4952
- Bigger member photo
- Removed "online since"
- Online Now/ Offline info under the photo - dependency #5007
- Display additional fields as chosen by admin - dependency #4126
This is major. As noted by karmatosed:
BuddyPress powers a range of communities... You could be proposing something to be used by a cribbage club for retired people, a football club, a school and a support group for an illness. You never know.
Hence, the admin should decide for her own community what info goes on the cards.
Member Profile
https://buddypress.trac.wordpress.org/attachment/ticket/5011/memberprofile-activity-1.9.png
https://buddypress.trac.wordpress.org/attachment/ticket/5011/memberprofile-friends-1.9.png
https://buddypress.trac.wordpress.org/attachment/ticket/5011/memberprofile-groups-1.9.png
Differences from #4952
- Bigger profile photo
- Friend button moved to top right. This is most salient place on the screen. Also, on directory pages, that's where the button is placed.
- Send Message button added to send a private message to the user.
- Online Now/ Offline info under the photo - dependency #5007
- Addition of 2 widget areas (content top and left column). In the example wireframes, the content top widget shows a preview of About/Profile?, and the left column widget shows a preview of Friends and Groups. - dependency #5008
Messages
https://buddypress.trac.wordpress.org/attachment/ticket/5011/messages-1.9.png
- Brought into standard profile-like template
- Added timestamp below title
- Folder links and Send Message button locations flipped
Replying to karmatosed:
During this week's dev meeting we discussed the best reporting method and it was decided Github will be for issues and this ticket will become the umbrella ticket.
You mean here? https://github.com/karmatosed/buddypress-templatepack/issues (asking as a bit confused as no issues there at the moment)
Discussions are welcome on any dev blog post (I post every week)
Here http://bpdevel.wordpress.com/ or on a different blog?
We work on these templates and release when they are ready and formed.
What does this mean? Mockups or actual template code? If latter, happy to help with a few templates once there is one or two completed templates up there.
#51
follow-up:
↓ 52
@
11 years ago
@sooskriszta:
We're not changing any milestone until reached 1.8.
There was no need at all to paste that contents here agin, it was noted and included already. Discussions have taken place earlier in this ticket also.
I am not going to debate this further as I really want us all to work together and not have conversations like this which don't leave anyone feeling good. Lets draw a line, you are welcome to be part of the process and encouraged to join the dev chats and like everyone else follow the process we're working together on.
Everything has had a complete discussion. All timelines have been transparent. Everyone is welcome to be part of this process and treated equally. I've not had things included, so have other users - way it goes with a project like this. Let's move on and create good things.
We've gone over your points, there was no need to include here again. I am not going to respond again and we need to just move on. I'm also recommending you do the same as this is taking time away from working on this project.
I encourage you just like others have / are doing to look at anything that goes beyond theme and is additional content to becoming a plugin - this was suggested before. Even if you experiment with it you can prove the concept - this rocks as a way to do things. A few things you list could easily fall into that:
- Extra widget areas
- Online/offline status indicator
- Additional admin fields
The latest dev blog entry is here: http://bpdevel.wordpress.com/2013/05/22/its-wednesday-its-also-14-days-before-feature/#comment-23440
There are no issues currently hence no show up. We now have a contribution format and guide to standards which we're going to release this week - that will make things clear.
You are welcome to be part of the template process, please come along to this week's dev chat and get involved. If you can then follow the dev blog or this ticket for more information. Templates are real code.
#52
in reply to:
↑ 51
@
11 years ago
Replying to karmatosed:
That's hardly fair. I created #5011 to discuss items we left out for the lack of time. You closed that ticket as a duplicate as the time issue has been resolved and suggested we have all the discussion here. Now, you are saying we won't have the discussion here either?
The issue is not whether "everything I want" is included. I created #5011 to discuss in detail the things that we hadn't been able to properly and completely discuss here.
#53
follow-up:
↓ 54
@
11 years ago
@sooskriszta: Every one of your points in 5011 have been discussed now by me. However, if anyone else wants to talk they have always been able to and will add their voice to this ticket. I'm not going over things. I'm not being unfair. I'm not repeating myself again. I'm also to be honest, not into the negativity this is causing so stepping away from discussions with you on this.
You are welcome to create plugins for extra functionality, you are welcome to be a part of the project, your feedback is welcome during iteration. Now, lets move on and create the templates.
#54
in reply to:
↑ 53
@
11 years ago
Replying to karmatosed:
Every one of your points in 5011 have been discussed now.
Beg to differ. "no time for this" and "I'm doing it this way" do not a discussion make.
your feedback is welcome during iteration
Whatever do you mean? This is iterating, isn't it?
#55
@
11 years ago
@sooskriszta: As it is important when you claim to quote someone. Nobody ever said "I'm doing it this way" every single thing has been debated and discussed here, on the dev chat and in wireframes previously - with regards to time it was a set time for wireframes already outlined in this ticket.
#56
in reply to:
↑ 16
@
11 years ago
Replying to karmatosed:
I was paraphrasing for simplicity and directness.
karmatosed
Nobody ever said "I'm doing it this way"
Well, actually, when @ubernaut and I brought up location of the Join Group button:
karmatosed:
I'm grouping actions in that UI so it fits there.
with regards to time it was a set time for wireframes already outlined
Nobody is blaming you or saying you didn't have good reason. I'm just pointing out that "no time for this" does stifle discussion and I had opened #5011 to remove this constraint. And now that this constraint is not applicable, it behooves us to have another look at things.
every single thing has been debated and discussed here
As pointed above, not quite.
I'm ... not into the negativity this is causing
I don't understand why this would cause negativity, and am sorry if it is. I'd ask you to look at it not in an emotional or personal way (nobody's attacking you personally, and everyone appreciates all your good work). Perhaps because I work with Scandenavians, Dutch and Germans a lot, I try to get direct to the point, instead of adding coats of sugar. This directness is meant to be efficient not offensive.
#57
follow-up:
↓ 58
@
11 years ago
@sooskriszta I appreciate some of your points here but also I would say that some are more to do with the theme author or site developer than part of a template pack, i.e members dir 'cards' while do look great with additional profile data ( & I do this when opportunity arises)that kind of customization is relatively advanced and best in the hands of a developer, in terms of providing that it would definitely require that the template pack then provide a full admin screen of theme option settings and while this has been mooted in the past it tends to get marked as something that core shouldn't provide.
I think the most important thing to understand about this process is that it is one that has been pushed for for a while and whereas there are possibly many options that could be looked into, ongoing discussions about how components could be handled etc these side projects can have a habit of running aground and stalling very easily.
I might have my own views on many aspects that are being discussed, but as a developer I'm more focussed on ensuring that finally we can get to markup templates in best fashion possible, visual styles I'm kind of happy to accept from the wireframes we have thus far and settling on those so things can be progressed and the whole process proved valid and worthwhile.
As for negativity I think this is a bad phrase, discussions are not negative however I always tend to think that there comes a point where there has been enough discussion and time to match with actual action less we simply go around in circles.
@karmatosed not sure what we have settled on or not but would advocate making a decision that this project milestone is changed to 1.9 ( given we have some notion of what sort of timelines 1.9 would entail ) think it makes sense to give it enough time to be done properly than to risk trying to possibly rush things to meet a deadline.
#58
in reply to:
↑ 57
@
11 years ago
Replying to hnla:
there comes a point where there has been enough discussion and time to match with actual action lest we simply go around in circles.
I understand, and I agree.
That's why I created #5011 to look beyond what we are able/willing to do immediately.
Don't we do this sort of thing (i.e. aspirational tickets) all the time when we mark ticket milestones as "Future release"?
Replying to hnla:
members dir 'cards' while do look great with additional profile data...tends to get marked as something that core shouldn't provide
Haven't seen that yet. But would love to continue that discussion at #4126
The idea is whether or not a backend for selecting the individual fields is available or not, certain decisions can be taken (for instance, the name of the flag used to indicate that a field would be included on cards) and the template should provide for it...for whenever the functionality is included in the core.
Perhaps that's not the right approach and a case of the tail wagging the dog.
Replying to hnla:
some are more to do with the theme author
We should let go of the notion that some stuff will be done by theme authors. There aren't going to be any BuddyPress themes. There aren't many now, and with theme compatibility we are killing them completely. (don't get me wrong - I think theme compatibility is the best thing that ever happened to BuddyPress)
Rather we should apply the same test that we apply when looking at features:
- Is this something that will be useful/valuable for a large proportion of the user base?
- Is this something that will create hardship for a large proportion of the user base?
(maybe there are more tests)
#59
follow-up:
↓ 60
@
11 years ago
sooskriszta said:
There aren't many now, and with theme compatibility we are killing them completely.
Not to add fuel to the fire or anything but i don't think i'd agree with either of those points. Granted compared to the universe of wordpress themes, themes designed specifically for buddypress are a much smaller group but there are more buddypress themes then there ever have been. i believe just because we have lowered the bar of entry for end users and site/theme developers it does not mean that those people would not have motivation to go further then what buddypress provides "out-of-box" in terms of design. In fact i would say that the demand for creative buddypress specific themes should increase in line with the larger installed base of buddypress installs.
#60
in reply to:
↑ 59
@
11 years ago
Replying to ubernaut:
there are more buddypress themes then there ever have been
There are 22 themes http://wordpress.org/themes/tags/buddypress tagged BuddyPress (in WP repository). 11 were last updated in 2010. 2 in 2011. So my estimate is that there are a sum total of 9 BuddyPress-compatible themes in the repository. That doesn't seem like many, though I have no point of reference to say whether that's fewer or more than "ever".
Replying to ubernaut:
demand for creative buddypress specific themes should increase
My guess is that most people will only use CSS adjustments. I suppose we'll just have to wait and watch. I am willing to be proved wrong.
#61
follow-up:
↓ 62
@
11 years ago
well the repository is hardly what i would consider "the marketplace" it may be the official place to find themes but it is hardly the largest or most active place to look for creative themes. themeforest for instance has another 18 tagged as buddypress themes (and i know many more available in their marketplace have buddypress styling even though they are not tagged as such) of those 10 are less then a year old and all of the older ones have received updates this year.
http://themeforest.net/category/wordpress/buddypress
i would be very surprised if we didn't see more buddypress themes in the next year going forward here is an example of that demand to enhance the "out-of-box" styling:
http://wpmu.org/how-to-create-a-custom-buddypress-members-directory/
note the 39 comments, 65 tweets, 306 likes and 60 plus ones.
#62
in reply to:
↑ 61
@
11 years ago
Replying to ubernaut:
i would be very surprised if we didn't see more buddypress themes in the next year
I can't predict the future and I hope you are right, though I don't have the same prognosis. (I assume you mean BuddyPress-specific themes, i.e. ones that ship with their own BP templates, because after theme compatibility release, probably *all* themes will be tagged BuddyPress)
Replying to ubernaut:
enhance the "out-of-box" styling:
http://wpmu.org/how-to-create-a-custom-buddypress-members-directory/
note the 39 comments, 65 tweets, 306 likes and 60 plus ones.
Funnily enough, 3 of the 5 changes made at this link were suggested on this very ticket and shot down
- Add New Location Field to members loop
- Increase avatar size within the member directory
- Customize the member avatars to be circular
- Change the layout of the directory
- Add a Greyscale effect to avatars on mousover
#63
follow-up:
↓ 64
@
11 years ago
well i like a lot of your ideas personally but i also would tend to defer to both karmatosed and hnla in terms of the progress of the tasks and not getting stuck in the mud. the basic notion of more is less is also something i would agree with.
i do believe the door is open for refinement/modifcation of the individual screens as had been mentioned as "iterations" but perhaps I'm misreading things.
at any rate i do appreciate the lively discussion! the only way great things happen is that people who care to make them happen take the time and care to do so!
#65
@
11 years ago
There is now a contribution guide and information up on Github for this project: http://karmatosed.github.io/buddypress-templatepack/.
Huge thanks to @hnla for helping create this. Please consider this a work in progress document.
#66
@
11 years ago
awesome going to dig into this sometime week i think will need some help with the pull request stuff also i do not have 2013 do i need to download the 3.6 beta in order to get that?
#68
@
11 years ago
As of today we have a lot more on Github (and continuing to add more). If you've not checked out the plugin for a while please do.
#69
@
11 years ago
This now loads as a plugin thanks to @boonebgorges. You can follow still here: https://github.com/karmatosed/buddypress-templatepack
We will have an update this week in the dev chat so anyone wanting to discuss please come along to the meeting.
#70
@
11 years ago
- Milestone changed from 1.9 to 2.0
As discussed in this week's dev chat, moving to 2.0 so we have more time for template pack goodness.
#72
@
11 years ago
What's the status on this? If we're at a point where it's ready for core scrutiny, let's get a patch worked up so we can start kicking the tires.
#73
@
11 years ago
The current project status of this is the following:
- Github project has the rough templates with about 70% styling.
https://github.com/karmatosed/buddypress-templatepack
- There are a number of issues with class/id (specifically) name changes that now mean a whole raft of things are broken. This is JavaScript/core related.
I do not feel it's patch ready whilst in such a state. It's not far off but it needs more hands than I have to see it through to the final stretch. It also needs hands that can do templates so we can create this patch fast. We have the wireframes, we have a lot of code, we just need that final push.
The bigger question would be whether this is desirable as something for core. If so, it is worth the push to get it there, if not it isn't.
#74
@
11 years ago
There's no doubt we would like for there to be more than 1 default theme compatibility option included in core. Whether that means what this is, something else, or something new, depends on the current state of where this is today.
From the sounds of it (being mostly broken) and without a champion to own both what's here and what's left, the reality is that's usually how good code dies young.
Are the issues over on Github complete and up-to-date? If not, is it possible to get a more detailed list of what exactly the state of your work is so far, so anyone else that wants to pick this up can easily take it over?
#75
@
11 years ago
I just want to be clear, I am more calling for 'hands on deck' and more than just me doing this than stopping championing it. More of an SOS than abandoning ship :)
I am happy to do more work on it if all agree it 'has legs'. Steering the ship solo for a while may have given me a slanted view but I still believe in this. I also am unable to complete parts of the scripting. I would hate for all the work that has gone into this from myself and others to go if there is going to be a template pack. The project needs to not be tied to just one person either - which it is currently. We need more than just a solo bottleneck.
I strongly feel whilst we can adjust some styling, the work that has gone into this deserves light of day. We had some good contributions from many folks on the wireframes and other stages. This is why I've pushed it along as much as I have.
What has been happening is working from the wireframes then checking off as each template is done. There needs to be issues created for the js / ids (thought there was but can't find it) and also for each of those templates breaking down into tasks. I can do that this weekend to give a better picture.
After thinking about this tonight, perhaps a better approach is this:
- Get that list up as I said. I'll try and go as macro as can for a good picture.
- Take 10 minutes (or as short as possible) time during next week's dev chat and all talk this through. I suggest a quick round robin approach through core team opinions/interest/comments first. Then briefly get other opinions/interest. If the outcome is lets continue building we ask for volunteers, even assign issues and make plans. If it's not other debates/opinions can happen.
I will note here something I do not mean harshly, we have to be aware that during building we need to be realistic about time people have available and also skills. There are plenty of opportunities to work on later stages of this once it's a patch. We need strong coding hands on deck at least first if this is to ever see completion. This needs if happens, to be a case of do not debate just to get a prototype. We can version, tweak and adjust until our heart is content once it's out.
At least then an informed decision of sorts can be made. Above all we need to not stagnate as that is where we are currently with this. I feel even today in some way we've moved on so that rocks.
#76
@
11 years ago
The project needs to not be tied to just one person either - which it is currently. We need more than just a solo bottleneck.
No reason it should be or have been though. I have contributed a fair bit and can do more and did push through updates as asked after xmas.
I'm happy for things to be considered as dual lead and together, I'm sure, Tammie and I can push things forward at a smarter pace.
Realistically though I think we need to have a notion of what is seen as the development timeframe for 2.0 to be able to gauge what is realistic to achieve for a product suitable for inclusion.
#77
@
11 years ago
@hnla: First up, thanks for stepping up. That's great you have time to get back involved. I want to be clear, I was not understating anyones contributions - what we have had is amazing. I know previously you said you couldn't contribute for a while due to the codex, if this has changed that is great.
I do have one little comment though, I don't think this is about co/dual leads or titles - this goes for my own role too. This is about hands on deck getting it done at this stage. You have just like me had admin status on the repo and always been welcome to commit anything you wanted. I know time was a scarce resource for you and am thrilled if this has changed. If anything has blocked you contributing please lets resolve that - I am always available on irc and Skype.
I am excited to see how we can work together to increase contributions to this.
#78
@
11 years ago
Not only would this be great to have available now that bp-default has been retired, it could serve as good practice or guidance to theme developers showing them how to build a theme the right way. Similar to how we have the skeleton component as a blueprint for component design.
I'm available to help test when needed!
#79
follow-up:
↓ 80
@
11 years ago
Question - how would a non-technical user download and install this pack? Also, does the pack automatically configure the hope page? The thing I liked about the old BP was it created blocks on the home page for the community. I'm lost on how to do this in the new version. Thanks!
#80
in reply to:
↑ 79
@
11 years ago
Replying to uxicorp:
Question - how would a non-technical user download and install this pack? Also, does the pack automatically configure the hope page? The thing I liked about the old BP was it created blocks on the home page for the community. I'm lost on how to do this in the new version. Thanks!
the template pack is currently under development (hopefully for 2.0) it is not finished yet, stay tuned…
#81
follow-up:
↓ 83
@
11 years ago
@henry.wright: I agree that this is worth while. It also is aimed at playing to the strengths of theme compatibility ie; not a theme.
@unixcorp: This is designed to load when BuddyPress does - it is not designed to be what you would use to make a theme from. It would work instead of a theme just like BuddyPress compatibility does now. Imagine you site has a theme, then you load BuddyPress. This would be what is output in the page when BuddyPress content appears. The structure.
@ubernaut: As has been for a while you just load it's plugin up and it works. It is not a theme.
#82
@
11 years ago
Ah, thanks! So how do we install it? I'm really only looking for the content on the home page that Buddy press used to set up in the carousel. Otherwise, I have a blank page...
#83
in reply to:
↑ 81
@
11 years ago
As has been for a while you just load it's plugin up and it works.
i have no idea what that means.
It is not a theme.
Not sure if i said that recently but thanks for clarifying anyway.
Hey i know you want the kind of help i'm not any good at right now (PHP/JS) but feel free to reach out whenever we're talking about CSS/HTML stuff love to help with any of that.
:)
#84
@
11 years ago
@unicorp: This isn't quite prime time ready yet and still being worked on. You can find all the details on how to use it here: http://karmatosed.github.io/buddypress-templatepack/.
If you do get any problems with it working then rather than add here, if you could create an issue on github for now we can try and deal with it. However, it is a work in progress and as has been discussed not ready to be used in projects.
@ubernaut: Thanks for the offer and there will as said be a place for everyone to contribute later. However, we at this time need more heavier coding, hence the call out.
#85
follow-up:
↓ 86
@
11 years ago
There are currently the following issues outstanding:
https://github.com/karmatosed/buddypress-templates/issues?state=open
The current status (with images) of each section is:
https://github.com/karmatosed/buddypress-templates/issues/38
https://github.com/karmatosed/buddypress-templates/issues/37
https://github.com/karmatosed/buddypress-templates/issues/36
https://github.com/karmatosed/buddypress-templates/issues/35
Whilst nothing is complete, the main areas that need more attention are:
- Members profile
- Messages
- Scripting issues as a result of the changes
I have today renamed the project to buddypress-templates to avoid conflict with the template pack and hopefully clear up some name confusion.
My plan is to over the next few days continue going through things so we can be in a good state to overview and decide a plan from Wednesday's discussion.
I understand opinions and respect them, but at this point a status report, then core feedback and then action is what is needed. We need to be very careful to not get caught up as we did in the past with this and use all that effort to move on the project. We can make all the tickets in the world and patches galore once we have something.
#86
in reply to:
↑ 85
;
follow-up:
↓ 92
@
11 years ago
I have today renamed the project to buddypress-templates to avoid conflict with the template pack and hopefully clear up some name confusion.
ok so maybe i'm still confused after all i thought the two things were the same. anyway thanks for all your hard work on this!
#88
@
11 years ago
@henry.wright: Whilst you are welcome to create one, it may be a bit early to do that yet as it isn't complete as a project. It's not been tested in browsers at all, or even tested beyond the work that is being done to create it.
This ticket was mentioned in IRC in #buddypress-dev by karmatosed. View the logs.
11 years ago
This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.
11 years ago
#92
in reply to:
↑ 86
@
11 years ago
Replying to ubernaut:
I have today renamed the project to buddypress-templates to avoid conflict with the template pack and hopefully clear up some name confusion.
ok so maybe i'm still confused after all i thought the two things were the same. anyway thanks for all your hard work on this!
Yes, seriously, what's the difference?
#93
in reply to:
↑ 91
;
follow-ups:
↓ 94
↓ 95
@
11 years ago
Replying to boonebgorges:
Milestone changed from 2.0 to 2.1
In the last 14 months, we've changed the milestone a few times. What's the expectation around whether it will stick this time around?
This is not to knock down the people who have been working on it (and have done a splendid job by the way), but rather an appeal to get this sucker out in the open with warts and all, instead of polishing it to perfection (if that's what they are doing now).
http://ma.tt/2010/11/one-point-oh/
Perfection is the enemy of the good. And we'll really only know the merits and deficiencies of the ideas when there are REAL people using it.
P.S. Happy to provide any CSS-related help.
#94
in reply to:
↑ 93
@
11 years ago
Replying to sooskriszta:
In the last 14 months, we've changed the milestone a few times. What's the expectation around whether it will stick this time around?
Completeness, in my opinion; template parts that cover the full spectrum of components (without duplicatingbp-legacy
).
This is not to knock down the people who have been working on it (and have done a splendid job by the way), but rather an appeal to get this sucker out in the open with warts and all, instead of polishing it to perfection (if that's what they are doing now).
This isn't a failure to launch situation. It's a lack of momentum and code coverage.
Perfection is the enemy of the good. And we'll really only know the merits and deficiencies of the ideas when there are REAL people using it.
Thanks for the reminder. We learned that valuable lesson in the 1.5 release cycle, when we waited almost 18 months to ship a version.
P.S. Happy to provide any CSS-related help.
Good to know!
#95
in reply to:
↑ 93
@
11 years ago
Replying to sooskriszta:
Whilst perfection an illusory construct and inevitably never achievable, we do have a need to ensure the templates are the best they can be and then the styles work to a best fit for many themes, there is always a concern to be taken into account where 'stuff' released into the wild and has uptake then becomes harder to possibly change after the fact without causing issues with sites already using templates & styles - there were things in bp-legacy I might have jumped in and improved & updated but doing so could have had implications for sites.
#96
@
10 years ago
@hnla Got it.
At the same time, we do need to have a sense of when we want to get it out.
At the moment, with no release date in sight for new template pack and an already 18-month old injunction on BP Default updates, it feels like a double-whammy.
Again, this is not to take away from the work everyone has put in. But I'm sure as one of the people who have worked on this you'll agree that till the users get to see the work, there's practically no solace to be had in the work that's been put in.
#97
@
10 years ago
P.S. I should have mentioned this in the previous message: Pardon my eagerness, but it partially comes from the fact that I don't see any blocking unresolved issues on Github
#98
@
10 years ago
- Milestone changed from 2.1 to Future Release
Templates aren't getting overhauled in 2.1; it's possible something might be done in 2.2, but I'm going to put this in the Future Release milestone for now to avoid filling the 2.2 milestone up with things we're not sure are going to make it.
This ticket was mentioned in IRC in #buddypress-dev by OC2PS. View the logs.
10 years ago
#101
@
8 years ago
Update for anyone arriving from search engines:
Thank you for your interest. A new template pack, bp-nouveau, is being developed at https://github.com/buddypress/next-template-packs where wireframes made by karmatosed for this ticket's template pack have been considered as well https://github.com/buddypress/next-template-packs/wiki/Wireframes Thank you Tammie :)
Status of the new bp-nouveau template pack as of July 15, 2016 is available at https://bpdevel.wordpress.com/2016/07/15/the-state-of-the-bp-nouveau-template-pack/
Putting in 1.8 for the time being.