Open Proposal Discussion: OOTP Web Dashboard

[ootpFox07]

[EDIT 10/20/11: Updated graphic attachments]

With the release of my Fantasy Tool and the resurgence of Getch and OOTPOU coming back into active dev, I have had a constant nagging thought for almost a year or so. It’s something I pinged Fidel about a long while back but I never articulated my thoughts on very well.

For a long while, I’ve had it in the back of my head that we have a number of great people making some great web based mods for OOTP. These include:

• StatsLab by fhommes
• Getch's Online Utilities by Getch
• The Free Agent Auction Tool by fmontoya
• Carya Game Log Viewer by rglass95
• OOTP Fantasy Leagues by yours truly

Each does what it does very well and all of these tools are well liked by the community.

What we don’t have between any of these tools, however, is either consistency in the way they’re developed or any sharing of knowledge or resources in how they work or even worse, are maintained. Looking at the list again, here’s how they break down technically:

Mod

• Technology
• Code Architecture
• Data Storage
• Code Versioning
  

OOTP Fantasy Leagues

• PHP 5.16+
• MVC (CodeIgniter 1.7.3)
• MySQL 5+
• Git (@Github.com)

StatsLab (All versions)

• PHP 4.36+
• Procedural
• MySQL 3.23
• None

Getch's Utilities

• Perl
• Procedural
• CSV
• None

Free Agent Auction

• PHP 4.36+
• Procedural
• MySQL 3.23
• None

Carya Log Viewer

• PHP 4.36+
• Procedural
• MySQL 3.23
• None

What we have in robust, “should be in the game” features, we lack in consistency, code reuse and resource sharing amongst ourselves. And while Frank, Fidel and rglass95 are all on the same basic technologies, how they're tools are built are all different.

Two examples of how were all overlapping but moving in different directions have really spurred me into action to create this proposal (though there are many, many more that can be dug up with enough time/effort):

• Frank, Getch and I all use a pretty similarly designed draft tool in our mods. The main difference to the draft code (apart from Frank and my custom interface changes) is that Getch’ is Perl, Frank’s is procedural PHP and mine is MVC PHP. We all have different ways we administrate and run the drafts and different interfaces. This in the end means we all basically have what is essentially the same basic draft tool, just implemented three different ways.What if we could be running the same core draft engine, just with our own custom modification on top? That way, Frank updates to include a live draft page would be available to both Getch and I as well. That way, we all can contribute to the same live draft interface.
• Another example is the Carya Log Viewer tool. This is awesome, but is built as its own standalone tool. For Frank, Getch or I to use this, we call have to customize it and adapt it to our specific codebases. So if rglass95 makes a killer change,, we’d all have to potentially start from scratch to update it all of our tools.

I just feel like were all a smart bunch of guys and there's no reason why we can't all be working towards the same goal: seriously kick ass OOTP web tools that work together. But again, all of our code is different so we need some kind of common ground to be the glue before we could potentially all start working together.

My proposal

My idea is to create a single common OOTP Site Dashboard that comes out of the box with a set of common tools, code libraries, user manager with built in roles and permissions support and a base group of shared OOTP functionality. Using CodeIgniter, the HMVC design pattern and a new Codeigniter library called Bonfire, a common, consistent site structure can be created, complete with a robust admin dashboard that allows OOTP online site admins to:

• Manage a single user base across all tools. These can be league members ot general web visitors.
• Load whatever of the above tools they want into their site as distinct and standalone modules
• Customize those modules with integrated admin options
• Select from one or more themes as their look and feel
• Present their tools in one common web site

This is a bit of a radical idea, but in the end, I think it would absolutely benefit everyone from us the coders all the way to the league commissioners trying to make sense of what were all building.

See the attached diagram for a breakdown of what I see the high level modular site architecture as being as well as a high level breakdown of how an HTTP request would be broken down and served.

The Benefits of this approach

• This provides the OOTP online community with a common consistent tool with which to manage the web apps they add to their site
• All OOTP web tools can have a consistent basis from which to start from. Common functionality that already exists won’t be necessary to think about so mod creators can focus on the specific and unique functions of their tools
• Each custom tool can be loaded side by side with other tools using a single module architecture.
• All tools will have access to the same member pool and member management tools, removing the requirements for multiple sign ups between tools.
• Member lists can be extended to include custom information specific to each tool using custom user meta tables
• Database changes can be grouped together and added or removed via Migrations
• Tools can be installed using migrations and a common install API. It will not be necessary to require a custom install or add anything separate.
• Common pieces of functionality between mods can be broken out as distinct modules or libraries themselves that can be accessed and reused
• Common Modules/libraries can be extended/customized by the tools if necessary
• Anyone in the OOTP mod community can contribute modules to this tool and they can be seamlessly dropped in
• This tool will support a shared theme library allowing for multiple look and feels

The best news about making this proposal is that Bonfire, mentioned above, already does the majority of these things. What we would need to do is revamp and plug out tools in using the module architecture, but that's also pretty much pre-set and pre-defined as well.

The Roadblocks

The distinct roadblocks I see to building a tool like this are:

• The framework would be HMVC - I know MVC very, very well and am now branching out to understand and begin using HMVC as well (My initial goal of any next phase of my OOTP Fantasy Leagues project would be to migrate it to an HMVC design before doing anything else). I don’t know if anyone else from our group knows MVC even a little. It’s not a difficult concept to grasp and master, but it would require people to step outside their comfort zone and learn something new on top of having to move their code to HMVC modules.
• The framework would be hosted on GitHub – Apart from learning HMVC, not sure how many of the group would be eager to dive into version control or specifically GIT. Again it’s not a hard concept to grasp and once you get it, it makes a world of difference, but there is a slight learning curve.
• The framework would be PHP/MySQL – One of my goals of this approach is to entice Getch to join the fold of developing tools and functionality within the same code-base. getch, you have great ideas and wrote a great tool, I wish we could all share the efforts more. There's a lot of overlap between Getch and Statslab that I think could be best put to revising functionality or collaboratively building new tools. Since Getch’s utilities are Perl/CGI based, this would require Getch to agree to migrate and learn an entirely new language AND way of coding AND adapt to using a database as opposed to CSV files. Getch, is this even in the realm of possibility?
• Time – When do any of us have oodles of time needed to execute this? Do any of us? Though the good news here is if we utilize Bonfire, the common infrastructure portion of the project is done and if there's anything lacking (of which I already have identified 3-4 things I'd like to contribute to the Bonfire team from my Fantasy mod), it's an open source project and we can do that. The largest effort I really see if identifying what shared functionality/resources could be shared and then making the conversion to HMVC.

So why do this?

• Single consistent code base for the existing and future HTML modders to use as a basis for coding web tools
• Shared library of common OOTP libraries and functionality
• No need to build infrastructure into tools. Just code the tool itself
• Extend existing tools, libraries and shared resources
• Common place for online league admins to manage their online tools
• Merge to power of some great mods into one killer suite of tools

I’m very interested in what my fellow HTML modders thoughts are on this proposal as well as the OOTP community at large. Let’s open this up for discussion.

[cody8200]

Wow, this is extremely fleshed out! I would love to see this integration as an end user.

[BleedingCubbyBlue]

Impressive. I wish I could help with coding, but basic HTML is about the extent of my skillset. I'm sure the OTBA and HBL would be happy to help with beta testing. When the times comes and you need beta testers, let me know.

[ootpFox07]

Originally Posted by cody8200

Wow, this is extremely fleshed out! I would love to see this integration as an end user.

If all works to plan, it should be seamless for the user. The backend handles keeping the code and tools organized. The themes allow for the UI to be whatever we (or they) want.

Originally Posted by BleedingCubbyBlue

Impressive. I wish I could help with coding, but basic HTML is about the extent of my skillset. I'm sure the OTBA and HBL would be happy to help with beta testing. When the times comes and you need beta testers, let me know.

Thanks BCB. I may just do that. And don't sell yourself short. The themes aspect of CodeIgniter/Bonfire isolates the HTML/CSS/JS from the back end code meaning you CAN contribute if that is your skill set.

New update on this based on some R & D I've been doing including updated diagrams and UI layouts coming in the next days!

[Getch]

The issue for me is time and motivation. There's a reason why I didn't do any work on OU for 3+ years; I just didn't have any desire to work on it anymore. That's changed of late, but it's still just a hobby to me.

Rewriting my utilities would be a lot of work, and it would stop being a hobby and more of a job. With other people involved, I lose the freedom to work on it when I feel the desire to. I work as a software developer all day, so spending 3-4 nights a week doing MORE programming will fry me.

I'm very conscious of burnout. I'm pacing the new improvements so that I don't get tired of working on OU, especially since I have a lot of things planned. I don't want the same 3+ year silence to happen again.

A rewrite into PhP/MySql would triple the amount of work that I need to do, only to end up with a very similar utility in the end. Don't get me wrong, PhP/MySql would be the way to go, but I have no desire to redo the whole thing from scratch. And there's a reason why I chose perl/csv, but that's a story for another thread.

Also, I can't speak for Frank, but I know he's been real swamped of late, and has no time to work on SL.

I don't disagree that the different utilities is a bit frustrating for users, especially with the massive amount of overlap between OU and SL. But these are free utilities that people wrote as a hobby and enjoyment... these aren't fullscale products released by corporations. I don't think we should try to make this into something larger and more complex than it needs to be.

A more toned down approach might be to make a utility that brings them all together, but acts as a shell. The individual utilities are invoked in a frame, and act exactly as they did before, but there's one common entry point/set of users/common database. Obviously OU is the black sheep here since it works against csv, so it wouldn't have a common DB. However, this would be doable with minimal work in OU at least to allow that.

I dunno, let me know your thoughts on this.

[BaseballMan]

I can help you with a Thanks and Great Job.

[ootpFox07]

NOTE: Graphics in the intro post have been updated to reflect some new insights into the HMVC process:

• Each module is now broken down into it's specifi feature set, not grouped by the larger mod type. So there would no longer be a concept of a standalone "StatsLab", "Fantasy Leagues" or "Online Utilities" modules. Everything would blend into one suite of tools. It would be the task of the UI design to organize and provide links to each module.
• I added the concept of OOTP Development using this tool to drive and power their suite of editing tools. This is more for Markus and Andreas.
• Resources can be shared, generalized and maximized for better reuse and development efficiency.

Now to reply to Getch:

Originally Posted by Getch

The issue for me is time and motivation. There's a reason why I didn't do any work on OU for 3+ years; I just didn't have any desire to work on it anymore. That's changed of late, but it's still just a hobby to me.

Rewriting my utilities would be a lot of work, and it would stop being a hobby and more of a job. With other people involved, I lose the freedom to work on it when I feel the desire to. I work as a software developer all day, so spending 3-4 nights a week doing MORE programming will fry me.

The best thing about this approach is that it's in no way an "all or nothing" approach. You don't have to bring over all of OU at once, you can convert and update say the Boxscores functionality and it's supporting resources and launch it, then take a break and move onto metrics, then voting, etc. Each module is a contained set of functions and resources and simply plugs into the dashboard (see my updated graphic for a visual representation of this).

The other good thing is that once this is in this framework you have at least one resource who can help out in me. As others try it and come on board, that more hands all working off the same basic setup. If you host your modules on Github (which I 110% recommend anyway), you have an easy way to review and merge outside changes into your module as well. My thought is, since are planning to rewrite many if not all your modules in OU anyway, why not just convert them to this concept instead?

Originally Posted by Getch

I'm very conscious of burnout. I'm pacing the new improvements so that I don't get tired of working on OU, especially since I have a lot of things planned. I don't want the same 3+ year silence to happen again.

I'm there. I meant to take a long winter hiatus off after the Fantasy launch but I dove right into this. Again, there's flexibility here to share some of the load if were all on the same platform therefore giving us all more of a break and keeping the energy flowing.

Originally Posted by Getch

A rewrite into PhP/MySql would triple the amount of work that I need to do, only to end up with a very similar utility in the end. Don't get me wrong, PhP/MySql would be the way to go, but I have no desire to redo the whole thing from scratch. And there's a reason why I chose perl/csv, but that's a story for another thread.

I am working on a demo which will show how CodeIgniter can help with this. Between the models, Migrations and it's built in ActiveRecord tools, DB work is usually the least of my development chores.

Originally Posted by Getch

I don't disagree that the different utilities is a bit frustrating for users, especially with the massive amount of overlap between OU and SL. But these are free utilities that people wrote as a hobby and enjoyment... these aren't fullscale products released by corporations. I don't think we should try to make this into something larger and more complex than it needs to be.

A more toned down approach might be to make a utility that brings them all together, but acts as a shell. The individual utilities are invoked in a frame, and act exactly as they did before, but there's one common entry point/set of users/common database. Obviously OU is the black sheep here since it works against csv, so it wouldn't have a common DB. However, this would be doable with minimal work in OU at least to allow that.

I can understand the hesitation. A wrapped i-frame based approach defeats the purpose, however, because it maintains the separate libraries approach. This goal of this project is to create one shared set of tools that everyone works from.

I have a demo that's 80% done and will show off some of the power of this concept. I'm merging concepts from you, Frank and Robert into one set of modules. Stay Tuned.

[ootpFox07]

In addition to the architecture diagrams in the first post, I thought actually seeing some of the admin tools I'm proposing for the the admin Dashboard might help to get people to wrap their head around the concept better. So attached are several wireframe versions of what the admin level pages would look like for the actual Dashboard module.

The settings show in these pages would be globally available and provide services to all subsequent OOTP modules.

OOTP Dashboard Admin Views Part 1

[ootpFox07]

OOTP Dashboard Admin Views Part 2