Skip to:

it’s been a long wait, are we getting close to the pay off? ; )

  • share test


    I’ve waited on this plugin for 1.5 years. I’m about to give up waiting and go to another plugin because I need a solution for my community and our groups. I would consider waiting a little longer, but based on the 1.5 year wait it’s very difficult to tell whether that would be a little longer or a lot longer.

    I understand there’s a possible target for end of first quarter alpha, we really have no idea when that might happen nor when we can actually use on a production site with group albums, which is necessary. Based on what we’ve seen I would estimate at least a late 3rd quarter 2012 production site launch (I guess that will hopefully be a nice early Christmas present for people). Do you feel differently on the timing? After this long on the project, perhaps a realistic, and not overly optimistic time frame can be set. I’m just wondering, is there a major hurdle that hasn’t been jumped? Is that why the estimations have been off so far?

    Has anything developed recently that fixes a major issue that would enable this plugin to come online for group albums as well in the next two months? What would be the minimum time for it to come online for a a live site?

    Thank you for your inspiration and hard work, I understand things do not always go as planned with development.


Viewing 7 replies - 1 through 7 (of 7 total)

  • foxly



    Its really difficult to predict dates things will be completed by because of the complex, co-dependent relationships between all the plugin’s components. The build process is more like painting a picture than building a skyscraper.

    We’re working very hard to get the plugin working as quickly as possible. Looks like we’ll probably have an alpha release for Q2, 2012.

    Regarding deadlines and such, we covered that in an earlier post:

    There seems to be some disappointment regarding the amount of time we’ve spent coding BP-Media versus what the plugin does when you run it on your server. That’s okay. It was planned for, and expected.

    So let’s talk about deliverables, dependencies, parametric design, management overhead, and project scope …which are the engineering terms for what many of you are complaining about.

    Say you want to fry an egg for your mom. Everybody knows how to fry an egg. You just put a frying pan on the stove, throw in an egg, cook it till its done, and serve it to your mom.

    The “deliverable” is the fried egg. The “dependencies” are the frying pan, which is needed to cook the egg, and the stove, which is needed to heat the frying pan.

    People frying eggs today have access to the vast amount of experience gained from frying millions of eggs in the past, and can use that experience to estimate how changing parameters will affect the deliverables. How long to cook two eggs instead of one? About the same amount of time. How long to cook an egg really hard? About 50% longer than usual. Frying an egg is a “parametric” problem.

    Furthermore, if any dependency in the chain is missing “I don’t have a frying pan to cook the egg”, it can easily be solved by driving to the nearest store and buying a frying pan.

    So even starting with no stove, no frying pan, and maybe even no kitchen, I can give you a reasonably accurate time and cost estimate for practically any combination of egg-frying you could possibly think of.

    When people talk about “how easy it is to write software” and “huge websites being built in a weekend”, this is the type of design they’re talking about (often without realizing it).

    And then there’s the Apple iPod.

    All things considered, using an iPod is about as complicated as frying an egg. It also has a dramatically smaller range of inputs (about 20 file types) and only two outputs (audio and video).

    There are two main reasons why the iPod took millions of dollars and years of effort to create, despite having the overall UI complexity of a kitchen stove:

    a) It has an enormous dependency chain. There are probably 300 different things …from the USB connection to the host computer, to the lithium-polymer battery, to the headphone wires… that *all* have to work before audio files put into the iPod come out as audio in the headphones.

    b) It was effectively the first of its kind. While there were a few other primitive MP3 players on the market at the time, Apple had to invent the “essence” of what makes an iPod an iPod, and they had to build huge parts of the dependency chain from scratch.

    Its hard to believe the iPod’s been around for over ten years now. Concepts pioneered in the iPod are now taken for granted and used everywhere.

    Building BP-Media is a lot more like designing an iPod than frying an egg.

    Although there’s tons of open-source software out there that we’ve been able to use to avoid having to write a lot of code, we’ve still had to write huge dependency trees from scratch (like our database class) and design completely new paradigms (like our Page, Album, Media, and Network modules). This work is ongoing and makes it very difficult to give accurate timeline estimates.

    In a “typical” software development operation, a significant portion of the development team’s time would be spent building “mock-ups” that would make the plugin appear to work in the user’s browser but wouldn’t actually do anything on the server. These “mock-ups” would be used to demo the plugin to the marketing team and executives, and would then be discarded. This is called “management overhead”.

    We’ve chosen to focus our development resources on building-out the dependency chain instead of producing “mock-ups” because we think its a better use of our time. We do realize this has created the appearance of little progress being made despite enormous amounts of code being written.

    Re: group albums

    No, we’re not releasing anything involving group albums in the next two months. Group albums are a very, very complicated thing to get right.

    For example:

    1) “What happens when a user adds an item from an album that they own which is set as ‘visible only to friends’ to a group album that is set as “public”.

    2) “Should groups be able to have multiple albums?”

    3) “Should anyone in the group be able to add items to a group’s albums, or just the admin?”

    4) “Should group members be able to delete other group member’s items from the group album?”

    5) “When somebody comments on an item in a group album, how should it integrate with the activity stream?”

    Download the latest nightly build and try it out…

    Follow our Twitter feed:


    share test


    Gratitude for the answer : ~)

    For the group album questions here’s what I would think:

    1) Personal and group albums have no connection whatsoever. If someone has something in their personal album, to get it in a group album, they will need to re-upload it. Same as facebook.

    2) Groups should definitely be able to have multiple albums.

    3) The group admin should be able to choose (from the group admin section) whether they want anyone or just themselves and moderators to be able to post images.

    4) No, only moderators and admins should be able to delete other group members items in the group album.

    5) If the picture is fresh and has just been added and is still showing up itself in the activity stream, the comment should show up on it, and you should be able to comment on it from the activity stream. Once the image itself is no longer showing up in the actiivty stream, commenting on it shouldn’t bring it into the activity stream, people will simply have to click on the picture to see the comments on it.




    With regard to Item 1, I partially agree with you. The owner of the content remains the owner. How that owner decides to spread that content whether through personal albums or group albums or whatever categorization the Buddypress folks come up with is his/her choice. Let’s say I have media from 2011. There is no way that I would want to tolerate having to upload the same media multiple times just so that I can have Albums for the four seasons or two, special events, by family member, or whatever weird grouping that I could envision for that year. It’s certainly not a green approach and would be extremely frustrating to the membership who don’t have the bandwidth of say, South Korea or Japan.

    It should be like iPhoto: I’ve got my library in the cloud and I can group in any way I want. Now if Buddypress Media could point to my iPhoto account, that would be something! ;-)



    @sharetest @qrahaman

    Looks like we have a productive thread here. So I’m going to put you guys to work.

    This is what a “functional specification” looks like:


    -If a user is inside a page module which:

    a) Renders only album modules
    b) Should logically give users the ability to create new albums
    c) The user has permission to create new albums

    -Then, the page module should:

    a) Display a link or button offering to create a new album
    b) Attach JS code to the page to open the create new album dialog
    c) Attach CSS styles to the page describing how to style the create album dialog

    -When a user clicks on the “create new album” link or button:

    a) The JS code should post a request to the server containing
    1) The method, function, etc, variables to tell the server which AJAX handler to run
    2) The page_module id (used to tell the difference between creating User Albums and Group Albums)
    3) The user_id (used to check authorization)

    b) The server should check authorization, and kill the process if the user is not authorized to continue

    c) The server should respond with the rendered HTML to load into the dialog box, containing:
    1) A list of the album types a user can create, with the number used and the number remaining (this avoids having to load the entire album module stack on every page view)
    2) A button to create an instance of each album type (disabled if the user has hit their quota for that album type)
    3) Encoded height and width parameters for the next dialog box for each album module (required by jQuery)

    -When the user clicks on a “create album instance” button:

    a) The JS code should post a request to the server containing
    1) The method, function, etc, variables to tell the server which AJAX handler to run
    2) The page_module id (used to tell the difference between creating User Albums and Group Albums)
    3) The album_module id (used to determine which module’s form to load)
    4) The user_id (used to set album owner if its a user album)

    b) The current dialog box should close with a fade-out effect (decreases perceived server lag due to page “doing something” while load is in progress)
    c) A new dialog box should open with a fade-in effect, sized to height and width set by the album module
    d) The dialog box should display an animated “loading” GIF until the server has filled the request

    e) The server should check authorization, and kill the process if the user is not authorized to continue

    f) The server should respond with the rendered HTML to load into the dialog box, containing:
    1) All data fields required to create the album type
    2) A “Cancel” button, which closes the dialog
    3) An “OK” button, which submits the create album request

    -When the user clicks on the “OK” button:

    a) The JS code should post a request to the server containing
    1) The method, function, etc, variables to tell the server which AJAX handler to run
    2) The page_module id (used to tell the difference between creating User Albums and Group Albums)
    3) The album_module id (module’s handler to use)
    4) The user_id (used to set album owner if its a user album)
    5) All data fields used to create the album instance

    b) The current dialog box should dim and display an animated “working” icon

    c) The server should check authorization, and kill the process if the user is not authorized to continue

    d) The AJAX handler should pass the data to the correct album module’s “create” function
    e) The create function should run all data through the DB sanitizers and note any failed fields

    -If there are failed fields:

    a) The create function should abort the create process and pass a BPM error object back to the AJAX handler

    b) The AJAX handler should parse the error object into
    1) The failed field names
    2) The reason each field failed

    c) The AJAX handler should JSON encode the data and send it back as a response to the JS code in the browser

    d) When the JS code receives the fail response, it should:
    1) Un-dim the dialog box and remove the “working” icon
    2) Reset all fields in the form to default status (handles case where the user has submitted the form, had failed fields, then corrected one or more failed fields)
    3) Fade the background color of each failed field to yellow
    4) Insert a tool-tip bubble above each failed field explaining why the field failed

    -If there are no failed fields:

    a) The create function should create an album instance and pass a success status and album_id back to the AJAX handler
    b) The AJAX handler should JSON encode the response and send it back to the JS code in the browser

    c) When the JS code receives the success response, it should:
    1) Close the dialog box
    2) Redirect the browser to the new album’s landing page


    Start writing one for “group albums”. Obviously, you don’t need to add all the coding stuff shown in the example above. *Just describe what the UI should do.*

    If I see a serious effort start to appear on this thread, I’ll add you guys to the project tracker and start sending the stuff you guys design out to other team members to get it turned into wireframes, templates, and code.




    Awesome to see some of the community willing to help us out :)

    Looking forward to installing this on my live site jamacast dot com. I checked out the download area for the beta version that was said to be ok to install on a live site. However, I felt a little confused and saw only files that had nightly build within their name so I wasn’t sure if they were beta files. I mainly would like to have this on my site, so I am willing to test some Beta versions. I only have a few users but have ample amount of post data. I also have a great understanding of marketing, and how the music scene operates as well a being in touch with many younger talent related to music industry. You couldn’t tell that probably by going to my site because I haven’t had anything come around yet that even gets close to what you guys have described in your detailed feature list. Everything I have tried up till now has fell very short. As I see design over all for media in general, musicians on sites are the types of people who do not want multiple menus, and places they have to click to go do some type of upload. They log in they get right there at a console to upload their music, and it magically appears all around them, this is truly how they feel when it comes to joining a music site, I have talked with tons of them. If one could make sure albums go right next to the lettle head user icon avatar area. This design would beat every design out there hands down, as far as real artist types are concerned. This should not have to be done with code it should be default just as the avatar is. Not sure how you have intended that type of design integration. I also recognize that that is probably more dependent upon the theme one uses. Judging by the progress of your plugin and it’s name, design is probably going to be a very big part and benefit for this plugin, along with ease of customiziation. I personally would rename any Album menu to Discography Room, Studio or any other holliwood catch phrase, also Media is a better choice in todays digital world. You might even want to include some stock Mp3 icons with the ability to group items into what could be called Mp3,Ogg,orFlac Packs. It would also be nice to have this plugin show a gallery mechanism right next to the user profile avatar that a visitor can flip through. This would be good for Artist, Musicians,Actors. Hope you don’t mind my input on design ideas, since this project is still in pre beta it seems. I’m sure I’ve not mentioned too much you haven’t already thought of or mentioned. Just me getting a bit excited to try this thing out. I will keep looking it over and reading up on it more to see where you guys are at. Also, I want to thank you all for going out of your daily lives to do this for masses of people in general, and for free!!! I think sometimes people forget all about how this system works via collaboration, and distant no personal relationships without giving, and getting the proper gratitude for your efforts at times. If and when my site ever starts to monitize on a regular basis. I will gladly contribute via donations for such type of coding endeavors. Right now I will patiently wait and see what comes out of all this. Don’t forget to let me know about the beta testing possiblities on my site. Oh and will this also become automatically available through my plugin manager area when it gets released, as an upgrade like all of the other plugins do or will I have to uninstall BP Albums and install the first release of the BP Media plugin?




    Well, we’re glad you’re excited about your site, unfortunately information presented as an 800 word long ramble is completely useless to us.

    Please review the post above giving an example of how to write a “functional specification”.


Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘it’s been a long wait, are we getting close to the pay off? ; )’ is closed to new replies.
Skip to toolbar