There’s a lot to like about Sage and i’m thinking of ways to use Sage more in the type of situations I am in these days. I’m getting a bunch of work as a sub (the main sub) for an agency. Although, I am the main, they may pull in one of numerous people to make a tweak here and there. Because of this unknown (who is going to be working on the project at any moment) I have felt Sage may be difficult to use for a person just coming in to make tweaks here in there.
I have been contemplating on how I might use Sage more in these types of situations. I have thought about just adding another un-minified stylesheet that could be used. Just wondering if others have been in these types of situations and thought of interesting ways to make Sage a bit more accessible when working with a lot of people and wanted to share. Thanks.
I do a lot of sub-contracting for agencies, and I use Sage for all of them. I suppose I’ve been relatively fortunate that a few of them have hired me because I use Sage/Roots tools.
However, if I don’t know who will be working on it after me, that’s not a deterrent for me as I’m still working on 99% of the development, and I’m not going to use tools that slow me down for the off chance that others might touch the project.
I’ve also found that other developers pick it up pretty quickly, especially when they see that the vast majority of WP sites at a particular agency have been built with Sage. I’ve also seen the other extreme… a non-developer has opened the minified CSS, made a few changes, sent it to me and said “please add this to the project”. Whoo
Even then, what’s holding you back? You are doing the vast majority of the work, correct?
Are you worried that since CSS files are minified, this agency will ask someone with very little web development experience to go in and change some CSS and not be able to?
If someone else will be working on the theme code alongside you, I would say this would be a great paid opportunity to teach someone else how to use Sage.
Yes. And yes, of course, we are using version control.
It’s not that they are really working beside me, they just get pulled in, here and there. Maybe it’s just an odd situation, but this type of thing happen a lot with this agency. Possibly it’s how their PM is interacting with their client, but there always seems to be “emergencies” and last minute things.
Anyways, if there were 1-2 people that would always be doing the tweaks, that might be fine to train. However, if a person comes in who is not so familiar with node., gulp etc… (and any errors that may occur) it’s just another barrier to entry to add to a possibly tight deadline. These are the things that I think about.
I’ve given these types of subjects a lot of thought, particularly since the future seems to only ever be more, new, different and more complex tooling. The conclusion I arrived at was that certain concepts and ideas simply cannot be avoided anymore. For example, five years ago there were still plenty of web devs who still used tables.
In my environment I try to make sure I can justify each and every change or addition to the workflow. For example - git? Absolutely and entirely worth a change in behaviour, even to non-technical people.
Another point worth making is that you can compromise on a lot of this stuff. It is difficult to get backed into a corner.
There are pristine ways to do things that I posit have incredible long-term benefits. However, what if that process blocks your short-term such that there will be no long-term?
What if, for instance, your team doesn’t know how to use bower? What if people getting fussy about bower is blocking your project? Just check your bower_components into source control and move on.
What if a package you need isn’t available on bower or github? Just download it like it’s 2006 and use it like regular.
What if people get fussy about the gulp build process? Just delete it and enqueue the assets manually like it’s 2006. The build process has massive, massive benefits but if one day it blocks you entirely: you are free to remove it.
Good to know, I seem to be hearing more WP developers that use version control. Happy to hear it
Obviously you know your own situation better than us. Like Austin points out, Sage is a starter theme so you don’t NEED to keep every aspect of it.
I would suggest discussing it with said agency though. Can you handle last minute updates? Can you help train one or two people who can make updates?
I would imagine that if a person is able to learn to use version control, they can learn how to run gulp as well, as long as it’s installed and working.
Thanks guys for all your comments. I am thinking I may try doing a build where I have an outside stylesheet and js that can combine for production when I do “maintenance”. If that makes sense. Then random people can do “hotfixes” whenever they want.
I’m having a similar problem with our workflow and the partner designer/devs. They’ve been using Ultimatum which i tried and has good points but a lot of bad ones too. But we did have a meeting and went through both and decided that sage with acf is the way to go.
I think your problem can be also fixed with communication. Sage is a high level dev starter theme (but same time easy for junior front ends). There is a learning curve but i think everyone wants to work at a higher level in the end. Just point out pros vs cons?
If there are fast tweaks you can always make a Custom CSS with ACF and they can do fast css tweaks from there and later you add them normally
But i know the feeling that after all the time you spent learning etc. to reach that high level, you need to go to a lower level because others aren’t catching up. Try and inspire them with Sage. Show them browsersync they will love it.
Also writing good documentation for your process would be nice for them.
I actually thought of this also. And then during “maintenance” I would just compile. This might be a good idea to just always implement in my projects. Then I can just say, “put it in there for now” if we have a timeline crunch or I am not around to explain things to a last minute sub.
If the next developer can’t figure it, and you’re not working on the project anymore, that’s not really your problem.
And I mean this both facetiously and seriously: I don’t really see why we should dumb down our process because of some theoretical future developer who may or may not have to maintain our project and may or may not already know how these tools work and may or may not be able to figure it out.
If it’s a team issue, I suspect, in a lot cases, the gains to improving the workflow and teaching other developers how to use said workflow are going to pay off dividends long-term.
Paying no care to ‘theoretical future developers’ is bad development practice in my opinion. I understand the hardline attitude and desire to push things forward. Would I want you on my team though with that attitude?
100% agree that workflow improvements benefit everyone and pay off long-term. Short term though, there’s big benefits to having a workflow that’s reliably documented, has some consistency and everyone on the team can at least jump in and do a basic hotfix from time to time.
There are sites I built 2 years ago as a freelancer on Roots 6 with Grunt, that I no longer maintain personally, but that I get asked pestering questions about because Roots is now Sage and when they do the logical steps of opening the readme.md and following the link to the documentation they get instructions for Gulp (just one example).
In the end as someone before mentioned, it’s a starter theme, you don’t have to use everything. I add/remove bits as needed depending on who will be working on the site, their technical ability etc. Does the company I’m building it for want a junior dev to maintain it? Fine I’ll do a handover, include some documentation and cater it to their team.
For the majority of work I do now which is all with 1 company, we built a starter project, tailored to our workflow, with elements of Sage, which I update occasionally and document for our needs:
This attitude of “If I’m not working on it anymore its not my problem” is just arrogant. Take the time to understand what features are and where they genuinely improve matters vs. overcomplicating them. It’s not dumbing down your process, it’s building something that’s usable by the team you’re delivering it to.
I think you’re misinterpreting the not caring about future developers. And as you say, there are benefits to an improved workflow. If you are the sole developer, you don’t have to worry about others jumping in. If you ARE working with others on a project, then yes, you should either train them on how to use this workflow or else choose one that everyone can handle.
To say it’s arrogant though isn’t correct. I don’t think it’s reasonable that if I’m building a project, taking 40, 80, 120 hours to develop it, NOT to use tools I’m comfortable with and speed up my workflow, in order to plan for the potential of someone else wanting to make a hotfix. Besides, if I was really worried about that, I would probably just save the CSS and JS files unminified and hand that to them, since who knows if they’ll be using a CSS preprocessor either.
“Responsible” developers, in my opinion, means coding responsibly. To say we shouldn’t use tools that help us in our work, to me, is the opposite of responsible.
Maybe arrogant was strong then… presumptuous? I just think as you rightly point out there’s a time and a place for using what you’re comfortable with and a time for going with what others in your team are comfortable with.
Base it on the comfort level of who’s going to be maintaining the code.
The attitude of “I’m not working on it anymore so not my problem” isn’t ever sensible. If you’re not around to explain to an impatient, less up to speed developer (they’re out there) who comes across what you built and gets confused and hates it, their grumbling is just going to reflect badly on you.
The ideal situation is to make sure it’s all documented and reversible. A “how to revert sage to 2006 for dummies” document is a good idea. Perhaps that should be part of the readme.
Main point of me chirping in was to share with the OP how what you choose is unique to the project/situation.
I’m hard-pressed to think someone complaining about not understanding the tools makes you look bad. It makes them to look unknowledgeable.
If they’re no longer paying you to do development, who cares what they think?
Maybe it is arrogant; if you know who’s going to be maintaining the code, there are things you can do to make sure they’re able to do so, including documentation, training, and the like, and if you’re in a situation where you have the opportunity to provide those services, by all means. I’m not implying you should throw the next developer to the wolves.
What I am saying is, if you develop a theme for a client, the client uses it without you touching it for two years, and then that client wants to hire someone less qualified to come in and make changes, I don’t see why we should dumb down our workflow for this theoretical developer. People you interact with, you can (and should) help. People you don’t or can’t, you have no obligation to change your workflow to accomodate.
they will love it.