Okay, first off, it’s been a while. Ever since joining WDS, I haven’t really had a reason to blog here, because well I blog there. But! I have an opporitunity to blog about more personal stuff with a series of posts centered around an experiment me and Eric Fuller are doing.
First off, we’re creating a new WordPress plugin centered around creating a todo list you can use when logged into your WordPress site. It basically will operate like this:
But, the reason we’re working on this project is because we want to experiment with the relationship between backend developers and front-end developers. We feel that the relationship between a FED (Eric) and a BED (me) can be a lot more smooth if we can only clearly identify who takes care of what and draw harder lines between (and even change completely) what a FED does and what a BED does when creating a feature.
So, I’ll be blogging the process here!
This week I basically scaffolded a base plugin using WDS’s plugin generator, definitely a BED task since it’s a plugin and not really a theme. One big hurtle for me was when I showed Eric what I had done. Thinking like a BED, I had tried to setup a template system of some kind that will allow Eric to add new templates and template parts/pieces, but then he told me, “I’m going to basically delete all that and have Js handle all the templates.” As a BED that really confused me initially, but Eric explained to me that he most likely was going to use Js/jQuery to build the HTML elements on the fly using JS, which for a BED means I don’t build any (maybe a bit here and there) markup, he does; that’s his job! I think too often BED get into the markup game, when really that’s a FED’s job.
So, next, Eric is going to basically build out what you see in that gif above, without any functionality. Well, almost. If you look at #6, he’s going to basically setup a static dataset for his UI to use. So, upon loading the page, his UI will be pushed to the DOM and populated with dummy data and should work for that page load instance. Creating a list or a new list item would simply push data to his dummy dataset (I think), deleting would remove it, etc. His entire UI is going to work off of a static dataset in JS loaded only for that page load. When the page reloads, it starts all over. I will be coming in when he is done and replacing that dummy data with actual data from an API request. The idea is he should have all the structure for the data worked out, I only need to ensure that data ends up being persistent.
Axios & Promises
One big change for me, as a BED, was Eric’s suggestion to use Axios and the understanding of JS Promises. Once I finally got my mind wrapped around Promises, it make complete sense to use Axios (a Promise based system) going forward instead of your typical
$.ajax() system jQuery uses. Usually the handling of data is handled by the
$.ajax() request itself, using callbacks like
compete which disconnects the JS. Promises are functions that run our AJAX requests, etc, and simply pass the data back to the caller instead of passing the data to it’s own
success method, etc.
Basically, Promises are functions that wait until your either resolve it or reject it, and that tells the caller when to continue using
.then. It was a bit to wrap around my head, but check out Axios and do your own research on Promises, they’re way better than passing the handling of a request, such as an AJAX request, to another function.
So, he can just setup a new
axios.get( functionThatReturnsJsonData() ) and later on, when I build the API endpoint for that data, I can just replace it with
axios.get( 'http://.../data' ). At the end of the day, as a BED, I do little markup! That is the FED’s job! The meeting place for BED and FED work will simply be JS, yet the FED drives most of the JS.
Me and Eric are working backwards than what we’re usually used to doing, which is basically: BED go create all the things then have the FED simply style it using SCSS. This time Eric, the FED, is going to drive “building all the things” since he is in charge of UI and UX! UX here is the most important, so it’s important that the FED (the designer) drive the UX initially. But, he’s not going to build out the data, that’s going to be my job after he gets the UI and UX going!
One thought we had was that using the build UI/UX first, and using dummy data initially is a good thing; to the point that we think any client could simply approve of the UI/UX first at that point without any BED intervention. Once a client approves of the UI and UX then the BED can come in and build out all the data. All too often changes in the UX/UI cause a lot of work to be done when it’s all build-out. This ensures the client approves only the UX/UI, and if they don’t we save the BED from having to do any extra work. The FED simply changes the UI/UX around, and makes a few tweaks to the dummy data (if necessary), then when the client is fully happy, the BED just has to ensure the right data ends up in the right places (they don’t have to worry about UI/UX changes at all, yey!).
This also ensures that the BED can design the storage for these items separate from the FED. The BED can also get a better grasp of how he might design the storage areas for this data (e.g. a CPT, or custom tables, etc) by having a good understanding of how the data will look. As a BED seeing the data first is always a good thing, rather than designing it before the UI/UX.
Takehome: UX/UI (FED) drives data (BED), not the other way around.