Cleecanth
commented
8 years ago Before I start, I just want to thank you for a thoughtful, well-reasoned post. I really do appreciate it, so I'll try my best to return the favor.
I completely understand, and — for the most part — agree with your points. The general idea of these templates is standardization in some form or another, so using a well-established framework would certainly help with that.
The largest issue, counterintuitively (I'll explain why in a second), is time and resources. Our department's frontend development team is split between me and two other developers, with this project being a tiny fraction of our overall responsibilities. Prior to this, as you might be aware, the templates languished without any real updates for nearly 6 years. Not for lack of desire, mind you, but because we have had to prioritize this among 3 truly massive sites (along with a dozen smaller ones, and a little over 80 internal applications).
This particular codebase is more-or-less a stripped-down fork of an internal framework we've developed over the past 3-ish years (public documentation here). The logic being that when we redesign med.wisc.edu, we will use a similar codebase, thus making the upgrade process for this (smph-department-sites) project simpler. Our decision not to use bootstrap on that framework is probably a little out of scope for this conversation.
Simplicity was another big consideration. Customizing/adding on to a framework can be a pretty project of its own, requiring updates that we don't necessarily have control of. It's not unlikely that we'd be stuck on bootstrap v.3 for quite a long time since this would be a unique codebase among our projects. Then, when the med.wisc.edu redesign rolls around, we'd be in a situation where the department templates would require a rewrite and still not be in sync with our other projects.
Along those same lines, we tried not to completely rewrite the previous templates. Since the skill-level and time available to the people who use the templates varies so widely, we wanted some form of a reference point for the "conversion" process. This explains the 11-column grid, some of the weirder class name conventions, and the less-than-stellar base typography. We cleaned them up a bit, but left some of the more widely-used styles in there. The hope is that we can alter these things over time (without total rewrites) and make the process less painful in the future.
As for lack of documentation — you are completely right and it's mine to own. It is nearing completion but isn't ready yet, which I know isn't much comfort to someone who has already started. When making a deadline for the 1.0 release, we set a goal of getting the documentation to a point that was at least as good as the documentation of the previous version. I think we got there, but we've got holes to fill in before it's complete. This effort would be somewhat mediated by using a framework, but obviously not enough to offset a rewrite of the a codebase.
To answer the issue's title, we more than likely won't be switching this project over to bootstrap/foundation/whatever, but that doesn't mean we wouldn't support a fork. And while that may sound like a way to shift responsibilities, it's really just a way of saying that we'll do whatever — within our limited set of resources — we can to support the needs of this project's users.
Ultimately we want brand, design, and IA consistency. Hopefully this project makes getting to that point a little easier.
Thanks again. I'll leave this open for future reference and discussion.
Preface: A lot of work has been put into this project, so take what I’m saying below with a grain of salt as its not meant as criticism. I don't think anything I mention below diminishes the work you've done so far (at least that's not my intent). Just putting it on github for comment and issue tracking puts it on a whole other level AFAIC.
If I may ask, is there a reason why, besides designer angst (I kid), this project isn't just a layer on top of Zurb's Foundation or Twitter's Bootstrap?
Perhaps it was to support legacy browsers/html or some directive to which I'm not privy. I ask because in these templates, I’m seeing a bit of a second system effect with the recreation of the same concepts as the aforementioned CSS Frameworks.
However, in my opinion, its being achieved with a less flexible/fleshed out degree, e.g. _smalls-c-8/c-8 _vs Bootstrap’s col-sm-8/col-md-8/col-lg-8 + col-sm-offset-8/col-md-offset-8/col-lg-offset-8 options, which would be expected given the much smaller resource pool vs the Open Source Bootstrap or Foundation projects.
It would be a much simpler approach to layer the needed SMPH assets on top of Bootstrap (or Foundation if preferred). Similar to how Bootswatch achieves it in conjunction with Bootstrap.
While I haven’t seen major issues with adding this on top of bootstrap currently, I have run into some basic conflicts/issues resulting from the margins/paddings within the current template, e.g. the choice of dividing by "elevenths" for your grid columns is having some issues with the other margins and the responsive elements are getting pushed down at times, essentially I think its a SASS floating point precision issue but I digress.
It seems to me that the SMPH templates are also lacking a lot of documentation regarding its components. Perhaps the compromise was to shift the burden to the developer needing to read the source code or it was for a specific persona, i.e. Joe web developer who is just looking for the design.
However if this were a theme layered onto an existing framework, many of the responsive items could be deprecated or moved to a legacy file, e.g. grid structure and size declarations. You'd be gaining a lot of items you are currently missing, e.g. text colors, column-offsets. Plus the established Frameworks are extremely well documented and continuously maintained. Bootstrap 4 is approaching launch too and brings a lot of nice features, e.g. cards, and they have the intent to support ver 3 for an extended period so support would be built in.
This shift would also free you from having to recreate additional components that are found within Bootstrap/Foundation and the documentation to go with it. It would also open up a significant amount of code and libraries that could be leveraged, e.g. Bootstrap DatePicker. You'd be able to create a small subset of SMPH specific items, e.g. SMPH navbar or header or SMPH color changes. This would be similar to what UW Communications’ is doing with their Bootstrap github project. For Documentation of their changes see the examples section.
I imagine you’ve probably already tackled this subject and I’m arriving late to the discussion. My motivation isn’t to criticize the work done as it achieves the desired outcome. My motivation instead arises from a desire for a standard. A standard that is well documented for easy uptake. In addition, it would have the added benefit of being one that is a transferable skill. As we tend to experience high turnover amongst developers at SMPH, having something that people are already familiar with is another simple win for on boarding of new personnel.
As I said, I hope this doesn’t come across as critical as its not intended that way. Thanks for all of your help in creating these templates so I can move to the design fairly quickly!