-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thoughts on regulations-site #8
Comments
I'm in favor of the outcome -- a wireframe version of regulations-site, but against a rewrite. I think it'd be a much better use of our time to move to this goal incrementally, starting with the CFPB-specific style sheets and slicing them off piece by piece. Right now we don't have good technology to get to either approach -- for ATF, we have a script which effectively
This is pretty hacky -- none of the Less files "know" they are being overridden, if that makes sense. The orchestration all happens in Python land. If we had a better strategy for this, I think we could start picking off CFPB specific bits and be on our way to a generic solution.
I think this is an orthogonal question. Whether or not we switch to a static site generator or something else doesn't really affect our frontend build system much. For the moment, django's template overrides work out just fine.
I think we absolutely want to preserve this, but again, it seems orthogonal towards the goal of creating a unified base which can be themed. |
Here's a summary of how I think this might work (moved from a chat conversation):
That’s just one idea, but would allow the developer the choice of how they’d like to work with those styles and avoid the potential |
To me a rewrite makes sense for a number of reasons. First, while I don't think it matters a great deal whether we use Django as a backend or not, the current way that we're using it is probably suboptimal. There's a ton of rendering of partials happening on the backend, in addition to a great deal of app logic that modifies the data extracted from the db. I think the correct way of doing this is to use the backend only for storage and render on the front-end; that's why we have things like Backbone, is so we can implement this sort of separation of concerns. Additionally, if we do it this way it should be easier to encapsulate the differences in appearance between different nodes in the tree; right now, the logic for doing this is very tightly coupled to the tree labels. Second, our API should ideally just be rolled into the main site project. Right now, in order to deploy eRegs, you need to deploy three separate components and god help you if you need t ochange anything about the logic of any one of them because then you'll need to make sure your changes don't affect anything further down the line. Just adding an extra field is a real pain, and it shouldn't be. As I've said before, I think a JSON-based db like Mongo would serve us much better here than MySQL. |
If we had infinite resources, a rewrite would make sense, but I don't see a good business case here. What does a full rewrite get us that an incremental upgrade doesn't? I think we can make all of the improvements you are suggesting without pausing progress for an extended period of time. I don't understand the desire to render everything on the front end. We're largely displaying text, after all, why not continue to use progressive enhancement? This approach is what's allowed the app to work seamlessly on older browsers, any page to be bookmarked without special logic, and every page to be crawl-able by search engines. I'd argue it's also what will make creating a static version of the site feasible a feat which would be much more difficult if all of the logic lived in Backbone. I think the pain around Backbone actually comes from the other direction, the assumption that Backbone should "drive" the app rather than relying on the backend for the proper data. I definitely agree that we should rework our templates. Right now, most are very aware of their context rather than being introspective -- we have lots of special case templates which are selected by the view code rather than having general purpose templates. I think Python should only provide the tree structure and the template should determine how to render it. Regarding separate components, I think your work on defining a schema will help a lot. If we had a single schema, we could also create a shared library which would prevent a lot of duplication and synchronization issues. On the separation between On MongoDB, |
So I think I probably didn't do a good job of explaining what I'm after Today, Adam and I had a chat about styles in regulations. One thing that This is a pretty minor example and trivially fixed (especially with the new I think this is a serious problem for expanding the user base for eRegs. With regard to a static site, I actually think it would be a huge As for storage, I think it's a secondary issue to the app complexity. I do I hope this provides a better illustration of the kind of issues I think On Tue, Dec 1, 2015 at 12:27 PM, CM Lubinski notifications@github.com
|
I have some related thoughts, and have put them in a gist, and you can feel free to comment there, here, wherever seems appropriate. From Slack: Here it is: |
I'm trying to go through the gist and leave comments where appropriate. I have a lot of thoughts for how this might be approached from a practical standpoint and it seems that we're more or less on the same page. 👍 |
Currently, regulations-site is a CFPB branded Django app. It's the result of a process where we were rapidly testing ideas and re-designing on the fly. This means that there are shards of code left where they shouldn't be and overall the app feels a bit messy.
As 18F expands regulations-site there is a need for it to be re-branded for various agencies. The current solution for this is to fork a version of reg-site. This works ok, but means that it's hard to contribute back to the original project.
Proposal
github.com/eregs/regulations-site could house a new and stripped down version of regulation site. This would contain minimal templates, styles, and JavaScript to produce a working regulations-site when paired with regulations-core. The output would look something like a wireframe.
Based on this frame of a site, individual organizations would be able to create themes that would contain template, style, and JS overrides (or complete replacements). This would allow organizations to style their own versions of eRegs however they'd like while also being able to use the base site.
Open questions
The text was updated successfully, but these errors were encountered: