BuzzerBeater Forums

I mean like take it over and start a discussion about it, like the 2nd team one.

There will surely be a newspost and a dedicated thread in BB-Global, once I get around to do it. For now, we can only try and find as much information about this as possible before deciding on how to proceed.

Nice suggestion mate, it would be great.

Well, I think the best solution for making an app, is hiring a professional.

Hey, I just wanted to comment again and say thanks for all the feedback, especially from BB-Marin! It's nice to know that this idea is largely supported and is hopefully in the works of being done. 125+ votes and a 90%+ Approval rating of this idea is awesome, so hopefully this progresses as it needs to in order to help BB and all the users that love this game.

to welington


brazil got embarrassed in the semis and 3rd place match, so would you still help BB -marin in developing the BB app? just kidding, i know you are now working on it. peace

LOL :)

Yeah, that was ugly. But it was deserved anyway, our team sucked.

We'll see how it goes, I've been working a lot since then, still need to talk to Marin.

Hey Marin

Wellington posted this previously.

I'm not sure how BB is coded, but if there was some kind of form or method to set up lineups, for instance, it wouldn't really be expensive or difficult to create an interface to receive roster data, enable users to play with it and then send it back. I know I'm talking about one simple functionality inside the game, but I'd recommend an incremental approach anyway.

This should enable the mobile devs to code an app without ever touching or seeing the code behind BB as they would only need some kind of spec of the data exchange.

This is my idea as well. Essentially you would just build a 'wrapper'. a GUI which communicates to the BB-DB and just grabs that user's data for setting lineups etc. No-game engine data or anything like that needs to be sent. All game data, such as box scores, play-by-play would be 'view-only'. just like how you have it now.
So the only thing that a GUI developer needs to know is that he is receiving data for a list. Essentially the developer is going to developer containers and lists that can handle the type of text data that the user needs to manipulate.

Also have a look at what other websites do - Some other websites offer a 'cut-down' or mobile-friendly version of their website. Less content, bigger text, etc, but still with enough functionality to get them by. Banks are a good example of this. You can't do everything with a bank-mobile app, but the core features are there.

So id probably look at the following to begin with:
a) A cut-down version of the whole site as a starting point. Put in in the core functions that you want people to be able to do. You want to give the users enough functionality to 'play the game' whilst restricting how much work you do. So for example. Set-lineups, forum posts, change training, put bids on players, asking for scrimmages, change drafting, sell/fire players, send in-game mail, arena building. Probably a few more things there, but limit it to that.
All other functionality would be removed, and only availalbe on the full-site.
b) An 'app' which directs users to the 'mobile friendly' website - Its kind of cheating as an app i know, but its essentially what other people do very often. And if a user is on a mobile device, if they type in the URL, they get redirected to the mobile site (ie: no app needed really). A downloadable app is just for completeness.

So thats what I would aim for for version 1. It at least gets it out there, would enable people to play the game on their mobiles/tablets.

Then see how that goes. If its a success, invest into bringing the entire site over.

Incremental - baby steps. even what ive suggested above is probably too big haha. But yer, small steps towards a longer term goal.

Good luck.

I began writing a mobile version of the site as a pet project for my own purposes a few years ago.. had some success using a combination of:

1. BBAPI
2. Mimicking the requests sent by the full site, and parsing the response to rendering it into a mobile friendly display

Option 1 gives you a lot of read only access - but for write access I had to use option 2 which got fairly painful as some requests could get quite tricky, and it was a fairly time consuming activity.

As many have stated previously, the most feasible approach to outsourcing this work would be a combination of BB-Devs exposing services that the App Devs can consume. Probably the easiest way is:

1. Crowd source the requirements of the App. What kind of functionality do users want to see? Filter the most common requirements that cover the majority of the users needs for the initial version - more features can be added in subsequent releases.

2. Construct a wireframe of the app to demonstrate the interface and functionality that will be exposed. No integration is necessary yet. Intent of this phase is to ensure the end users are happy with what is going to be developed. Constructing a wireframe also helps with identifying integration requirements - what calls to the BB backend are necessary to deliver the functionality required on each screen?

3. Work with the BB-Devs to expose the required functionality. The easiest way to do this would be for the BB-Devs to do some dev work on their end to expose this functionality through SOAP or REST services. This would essentially be a big expansion of the REST API.

4. Voila, you have your App. Not only do you have your App, you also have a new set of exposed services that will expand the third party community to do things more powerful than ever. This can be a good or bad thing.

I would probably question the need for HTTPS. This makes the solution a whole lot more complicated (you'd need certificates, more complex coding, more load on the servers etc.) The full site doesn't even use HTTPS, why should the mobile site?

2. Construct a wireframe of the app to demonstrate the interface and functionality that will be exposed. No integration is necessary yet. Intent of this phase is to ensure the end users are happy with what is going to be developed.

I remember I used to believe that showing user's wireframes was a good idea. Lets get user input, yer it will make them happy to know that they are getting what they want.

However now, after years of bashing my head against the wall from hearing feedback like "I want a button that looks like Hello Kitty!" im now of the belief that it is easier to just go "This is environment, if you don't like it, don't use it".

now that might not be the best attitude for a commercial product, but honestly, i could not imagine trying to coordinate the input of thousands of user's who 'think' that their input of the design of the site is the right way it should be done. You will never make everyone happy. As soon as 1 idea of the majority is not implemented, they will focus on that 1 missing idea and have a negative attidude about the product. HATE THIS about user engagement. *shudder*.

Ironically, ever since ive adopted a 'this is the interface' attitude, you do get more post implementation criticism, but as soon as you put a price tag on the changes, criticism is quickly shut up. haha.

You already have an app. It's called your browser and you get it on your phone.

How is there time to 'whip out' your phone but no time to 'whip out' your laptop? Is secrecy the key?

Your claim that the younger crowd will use computers less is interesting. Are they going to get rid of the internet? Do you think everything will become an application?

Players come and go for many reasons. Age, boredom, life commitments. Whatever the reason, people move on from things all the time.

There, problem solved.