Project: Cohort Module Enhancements

Community GSoC
, ,
1

This thread is dedicated to the Cohort Module Enhancements project for GSoC '16. @maimoonak, @sharonvarghese and myself will be using this thread for official discussion and progress.

The thread where pre-GSoC discussion for the project took place can be found here.

2

Hello @darius, @burke and others,

During the Design Forum on the 4th of May we discussed what steps had to be taken to carry this project out in the right direction. Some of the valuable suggestions we received, in a nutshell are:

  1. Design the module so that Dynamic Cohorts can be supported in the future
  2. Rewrite the code for the complete UI (Angular included)
  3. Make the UI in a separate module, preferably as an Open Web App

There are a few issues if we were to proceed this way:

  • First of all, the current architecture of Cohorts is such that it does not support Dynamic Cohorts. So building something currently keeping in mind a feature that is not yet implemented seems difficult. That being said, we will make sure that during the progress of the project we’ll make sure that we don’t implicitly assume we’re working only with static cohorts.

  • Second, implementing the complete UI as an Open Web app would require rebuilding the entire UI from scratch and also experience and knowledge in Polymer.js I believe, which has a learning curve attached to itself and the time period allotted for GSoC is a bit too short for that.

If we were to go ahead with the project keeping in mind that we want to generalize it and integrate it into core ASAP (and I believe that is the plan, which sounds awesome) there is a good chance that the project still remains quite unusable as it is right now (Again, time window for GSoC).

@maimoonak mentioned in the meeting that her organization already has a use for this module in their project. In fact, @sharonvarghese worked on the project keeping in mind the requirements for Maimoona’s use case last year.

So if we are able to complete the project as per her requirements and they can actually use the module on a practical basis, that would be a great achievement in itself :slight_smile:

We can work on integrating the module into core in future projects, presumably when the architecture can support Dynamic Cohorts so we can leverage that into the project.

Tentatively, the final plan is as follows, as per my proposal:

  1. In Coding Phase 1, revamp the complete UI and add features that allow us to manage, edit cohorts. Add a dashboard and integrate a search widget. This was one of the primary features needed for @maimoonak’s organization if they were to put the module to use. The plan is to use jQuery and Bootstrap since that would really speed up UI development and is easy to work with.

  2. In Coding Phase 2, complete the HFE integration, which should allow us to crate cohort-centric forms. Also, the REST endpoints will be redone.

While we do know that this was not the optimal path to go ahead, keeping in mind the time constraint and also not wanting to keep the project unused for presumably another year (until the next SoC) we decided to go ahead with this so that atleast it is completed and usable for using in a set of particular scenarios.

On a sidenote, we plan on utilizing the Agile board to keep progress of code and milestones as tickets in the form of a sprint. I’ll post a link as soon as it’s ready.

Looking forward to your views and opinions!

Cheers, Shreyans

3

@bholagabbar, it’s up to you and @maimoonak to decide on the best way to use the GSoC time to work on this project, and we will support whatever decision you make.

I disagree with two things here:

  1. OWA does not require any specific JS library, and it definitely doesn’t require Polymer. Although I would personally recommend that you take advantage of this opportunity to learn how to use a modern JS tech stack (e.g. following what @raff and soldevelo interns are working on here), you could also do an OWA using jQuery and bootstrap.
  2. I understood from the design call that there is not very much existing UI, and you’ll be adding a lot of new screens and features, relative to what’s there now. From glancing at your mockups, I would think that writing from scratch in any technology other than JSP is going to be faster, even accounting for the learning curve.

Is this different from what I suggested on the design call, which is to rewrite the UI while adding your new features? (Maybe we’re just using different terms for the same thing, but I don’t know how you would “revamp” a JSP-based UI to use jQuery and Bootstrap in a way that’s different from a “rewrite.”)

Regardless, if I’m understanding you right that this will be HTML + JS client-side code, you should do this in an OWA.

I’m assuming that when you say you’ll use jQuery and Bootstrap that you intend to make this more of a client-side app. If that’s the case, REST endpoints need to be redone as part of Phase 1. (But I thought the REST endpoints were already nicely functional.)

1 Like
4

I’m still in the process of discussion with my mentors but since you’re saying that OWA are the way to go, then I think we will start looking that way.

EDIT:

I would like to comment on the REST part you mentioned. Implementing the OWA as of now just might not be possible with the current REST we have for the module. Even if I were to finish of redoing the REST endpoints again, I wouldn’t really know what I might need until I really start implementing the UI. What I’m trying to say that the module is still really in beta stage right now and I’m not sure if we can rely on the extensiveness of the REST API it provides.

If I work on the UI in the existing module, it would be really easy to make changes to the controllers and database because like the API code is right there. Suppose I would like to introduce a feature that requires me to get something extra from the backend, it would be really easy to create a new Controller, add that data to the Model and send it to the view.

I don’t have a lot of clarity in mind on as to how to proceed for the project and would really like all of us to unanimously decide on how to proceed ASAP. @darius @maimoonak @sharonvarghese

5

A post was split to a new topic: Cohort Modules Enhancement Project

6

Please move discussion to the #dev category.