15

I build quite a bit of projects with a friend of mine, but we always come to the same pitfall over and over again. I know how to write PHP, Javascript and all that of stuff (I also know CSS and HTML) so I can do most of the work when it comes to building the actual functionality. However, he can't, but he can do something I barely can: design the sites.

But every time, we stumble upon an issue, since he doesn't know how to write code, it generally slows down our development quite a bit. At the moment this is our workflow:

  1. We come up with a feature
  2. He builds the front-end design (where it should be placed, how it will look etc.)
  3. He sends the complete template to me (the HTML export from Pinegrow)
  4. I look for the changes he made, then implements them in the actual site (since a few weeks, I use CakePHP for it).
  5. when something doesn't work out as intended (like for example, it didn't work out as we planned for some reason), I fix the issue on my side, then send him the template back
  6. rinse & repeat

This process, as one could imagine is painstakingly slow and inefficient. So my question is, how can we make this process go smoother? I've seen a lot of stuff about that we should use React and use RESTful and what not, but we want to use CakePHP for it. Could some people guide me to some helpful resources about it? I've been looking for this for a while now but never came to a decent solution for this.

Basically, all my partner can do is designing the site. He can't use Docker (I use Docker all the time), PHP, Javascript and pretty much anything else (he does know some CSS, but mostly works with a WYSIWYG editor) I'm willing to learn it to him, but he is not interested (so I have respect that). I hope somebody here could help me (and probably others coming by this question later) out with this as I think it's quite a major thing.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
Finlay Roelofs
  • 261
  • 1
  • 5
  • 4
    I don't quite understand what your problem is. This is how Separation of Concerns works; he writes the template in HTML, you write the rest. He shouldn't need a Docker container to do that, nor PHP or Javascript. You're already doing it the best possible way. If the problem is sending it back and forth, put the whole project into a Github repository and share it (you need source control anyway). – Robert Harvey May 19 '18 at 14:15
  • The thing is that it takes a boatload of time in the longer run, and can cost me extra time if he's like: "no, i should actually do it like this instead". then i have to start back again. – Finlay Roelofs May 19 '18 at 14:17
  • 1
    Unfortunately that's the nature of iterative development. Things change. If the issue is that he sees the completed, working design and decides to completely change it, then you need to tell him to give you designs that are already pretty close to the actual finished product. – Robert Harvey May 19 '18 at 14:18
  • I see. I always thought that there was a more efficient route to this. so either he has to pick up using PHP and Docker and everything (so he can do the same things that I do), or we have to keep it like this? – Finlay Roelofs May 19 '18 at 14:22
  • @FinlayRoelofs: if I got you right, the problem is you cannot reuse your friends html templates directly, but need to rebuild the UI in code separately, or merge the code with the HTML with much effort? Sounds more like a tooling problem. – Doc Brown May 19 '18 at 14:29
  • 1
    Yes, I have to copy all the changes to my code and add the dynamic stuff in (like forms generated by CakePHP n stuff). If I just use his templates directly, I lose all the PHP code that I already put into it – Finlay Roelofs May 19 '18 at 14:31
  • 2
    Can you sit together in one room, using one computer, and integrate your work? Pair programming can be super effective for these kinds of problems where you need to bring two skill sets together. – amon May 19 '18 at 15:07
  • If we could, we would probably have done that :\ but he lives a bit too far away to do that every day :\ – Finlay Roelofs May 19 '18 at 20:35
  • `If I just use his templates directly, I lose all the PHP code that I already put into it` -- It really does sound like you need source control. Everyone who is serious about software development uses source control, and if there's more than one person doing development, source control is *essential.* Source control is *the way* multiple developers coordinate their changes. Consider getting a free Github account and teach yourself how to push changes to it. Then teach your friend the same. – Robert Harvey May 19 '18 at 21:48
  • We have looked into using Git before (I use it a lot for my own stuff already), but last time we tried, we kept overwriting one and anothers files all the time. – Finlay Roelofs May 19 '18 at 22:36
  • 3
    @FinlayRoelofs then you might consider *learning* how to use git. You should each checkout each other's code before pushing your own, then you're always on the same page. – Zymus May 19 '18 at 23:22
  • @FinlayRoelofs: why don't you use a screen sharing software like TeamViewer? I do this daily with my colleagues in our other departments, hundreds of kilometers/miles away. – Doc Brown May 21 '18 at 07:16
  • @RobertHarvey: source control does not solve the problem of using incompatible tooling (Pinegrow vs. CakePHP) for the UI parts. – Doc Brown May 21 '18 at 07:29
  • @FinlayRoelofs: what you really need is probably switching to a technology with a better separation between UI and presentation logic. I am not an expert for PHP web frameworks, so I cannot give you a good recommendation here, but coming from the Microsoft World, that is exactly the idea behind WPF & XAML: having a tool like Blend for designers, and a **compatible** framework for the devs. You should look to find something similar in your Eco system. – Doc Brown May 21 '18 at 07:34
  • @FinlayRoelofs: maybe [this SO question](https://stackoverflow.com/questions/13980883/how-to-separate-html-from-php-files) helps you? Don't know how applicable this is in the context of your tooling. – Doc Brown May 21 '18 at 09:28
  • @DocBrown: I wasn't aware the tooling was incompatible. Surely the HTML so generated isn't. – Robert Harvey May 21 '18 at 14:50
  • Maybe put project on GIT and add autoreleaser to some development server. When he sends you page first time put it in Cake and now when he needs to make small changes he can change it directly in Cake (not all but some simpler changes) and immediately see result on development server. – Volvox May 21 '18 at 15:06
  • I'm currently giving the guy a bit of a Git bootcamp in the hope that'll work, while I am also looking to increase my Git knowledge (currently, I already have a decent knowledge due to my actual job heavily using Git for everything, but learning more can't hurt). Also my friend is looking into Adobe Dreamweaver at the moment (since they want to start using that on his workplace), and by my knowledge, that does support PHP via an external server (which can hook directly into my Docker stuff, 1 command and he's up) – Finlay Roelofs May 21 '18 at 20:17

6 Answers6

26

Want to free your Front End Designer from the code? Want to speed up integration? Want to use the professional techniques used by the slickest web sites? By far, the best tool for this is:

Paint.

Yes Paint. Well some drawing program anyway. Let him take screen shots of your site, move things around, and add things he finds elsewhere. This will let him work at the speed of his ideas and free you to bend the code into whatever shape works best for you while giving him what he needs.

If that's still too slow, say because the customer is in the room with you both, I recommend a much more advanced tool set:

Paper, scissors, and tape.

Maybe a pen if you're feeling ambitious.

I've used this technique to successfully get decisions on the theme, style, content, and major features for a site at a table in a Panera Bread with a customer before anyone realized we were done eating.

That will make him fast, it will free you from his "code", and it's actually the most powerful way to develop a user interface. He can start doing usability tests before you've written a line of code.

You may be thinking "oh this is fine when getting started but you don't use this once the site is developed". Not true. It works just as well on stable sites. But now most of the screen shots come from your own site.

What if your Front End Designer wants to use some code generating tools to make his mock ups? Fine but don't think for a second that you have to use his "code". What you need to respect are his decisions about look, flow, and presentation. What happens behind the curtain to make that happen is not his area of expertise. It's yours. Take responsibility for that.

Just respect his work enough that when you're done you show him how it turned out. Let him nitpick everything the user would experience. Be prepared to get hit with new ideas.

This is iterative development. Don't do a lot before asking. Do as little as you can. Ask as often as you can. Put toys on your desk to keep him entertained while you implement his latest idea so he can review it as soon as it loads. Keep going like this until it's time to meet with the customer.

If the code your Front End Designer produces is actually worth the trouble then you need to learn to integrate your code with his. For this I strongly encourage you to learn source control. Learn it so well that you can teach your Front End Designer how to use it.

Only once both of you can reliably use a source control tool do I recommend that you base your integration plan on merging code. At this point your friend would deserve a title change from Front End Designer to Front End Developer.

Now even if you do this, it wouldn't surprise me if the doodling-on-screen-shots technique doesn't still turn out to be the fastest way for you two to collaborate.

Maybe you just can't take the chaos of all these changes. It's creating too much work. Well it's called software because it accepts change. Otherwise we'd have an Electrical Engineer do it on a specialized chip. It could be you need to reachitect to move your behavior logic out of the user interface so UI changes won't impact your core business rules. If you speed up your Front End Designer you need to be ready to keep up with them.

The only good reason to force a Front End Designer to produce code is because you're tired and want to slow them down. Well, I guess that's not really a "good" reason.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • I see what you say, but the thing is, there is no customer. We build the projects by ourselves (generally we come up with an idea and try to build that in an actual function thing if we thing it's actually doable for us). We already use Git for most of the things, but I still have to add the changes manually (doing a marge ends up with either my or his code being sorta pretty much ehm... gone) – Finlay Roelofs May 19 '18 at 20:39
  • 1
    Then the customer is each and every user. Anyway, if this is true: "since he doesn't know how to write code, it generally slows down our development quite a bit." then stop making him work with code. Try it the other way. He will cause you nightmares without knowing why if you keep making him think he has to give you code. There are [really](https://ux.stackexchange.com/questions) [awesome](https://graphicdesign.stackexchange.com/questions/109575/width-of-glyphs-for-logo-design) people in IT that never touch code. Give them some respect. Let them do what they love so they can shine. – candied_orange May 19 '18 at 20:55
  • Well, he doesn't even touch the code at all. He builds the design in Pinegrow, and with the click of a button, Pinegrow exports all the HTML, CSS and Javascript for him. He then just sends me those files. He never even has to see the code itself. – Finlay Roelofs May 19 '18 at 21:04
  • Which is exactly why you're going nuts when you integrate. You now have to publish everything you do twice. Once to update the site. Once to get his template in sync with the site. That's awful. Either teach him to pull your code changes himself or let him work from screen shots. – candied_orange May 19 '18 at 21:12
  • step 5 of the way we do it now isn't that big of a deal (I suppose we could use a cloud service like dropbox for that?). The biggest thing is me having to manually check for changes and implement them. That is the step I have to make more efficient. – Finlay Roelofs May 19 '18 at 21:15
  • One of the nicest things about working from printed screen shots is the old stuff is pixels and the new stuff is ball point ink. Really easy to tell apart. The rest is just doing the actual coding work. If you find a way around that let me know, I'll make you rich. Hint: if you're thinking of something involving the mouse just stop now. – candied_orange May 19 '18 at 21:23
  • 1
    I have used Powerpoint for this - think paint on steroids. I used slides to show sequences of work flows etc.... – mattnz May 20 '18 at 05:34
  • 2
    @mattnz sounds awesome. The most important thing is to bend the tools to your purpose. Not let the tools dictate how you are allowed to solve problems. Let me do my own thinking. – candied_orange May 20 '18 at 05:38
  • 4
    +1, the core issue here is the friend using Pinegrow and them expecting that to easily integrate. – Paul May 20 '18 at 13:59
  • I upvoted this answer because it identified the problem of having the cut between the two workflows at the wrong place, and it presented a possible (but IMHO not satisfying) solution. However, I am convinced there must be a better solution to this, where the designers can work with some modern UI tool and their changes don't collide with the code written by the devs. – Doc Brown May 21 '18 at 07:39
  • @DocBrown Thank you. I mention how to handle such "code generating" UI tools in paragraph 10. I also mention that code producers (all kinds) should use source control if they want people to use their code. Not expect someone else to do your pull and merge for you. If you can't do that there are other ways to use your work. – candied_orange May 21 '18 at 10:38
  • @CandiedOrange: see my four last comments below the question. I am pretty sure source control (though required) is not the solution to the core problem. One needs to find a better tooling to separate the UI artifacts from the PHP code. Your proposed solution is not to let the designer produce any artifacts for the "real" HTML templates, that is surely a solution, but I am sure there must be a better one. – Doc Brown May 21 '18 at 10:47
  • @DocBrown updated. Better now? – candied_orange May 21 '18 at 11:39
  • @CandiedOrange: you got me wrong. Your current line of answering IMHO cannot be improved by some fixes to your answer here and there. I guess what I expect requires knowing the specific tooling of the OP, their "overlapping responsibilities" (which is IMHO causing the trouble here) and maybe a suggestion how to fix this, either using the tools differently **in a more efficient manner**, or using different tools. Yes, you made a suggestion of using the tools differently, but I don't consider this as really more effcient. – Doc Brown May 21 '18 at 12:26
  • @DocBrown In my experience it can be amazingly efficient. I've worked both sides. The way I understand the tooling problem is they both want to use different tools (Pinegrow and PHPCake) that generate front end code . These two tools are not integrated so each time one is used it damages the work flow of the other. The way I understand the "overlapping responsibilities" problem is the OP is doing all the merging and is deploying to both the site and to the Pinegrow workflow while trying to keep both in sync. – candied_orange May 21 '18 at 14:32
  • @DocBrown I have proposed the OP stop taking responsibility for keeping the front end designer in sync. I have proposed using pictures, not code, to consume the work done in Pinegrow/Paint). I have proposed use of source control by both parties. Baring that the front end designer can consume the site itself to stay in sync. I have suggested rearchitecting to minimize the damage that Pinegrow does. I'm willing to make any sensible improvement if you can make clear what you want. I'd also welcome your own answer. I'm sure there is plenty I can learn from you. – candied_orange May 21 '18 at 14:32
7

In terms of tools, the optimal workflow I've see is using Sketch and Zeplin. Sketch is a straight-up design tool. Equivalent to Photoshop or InDesign, but optimized for designing apps and web sites. Zeplin is a tool for sharing and approving designs in Sketch (or Photoshop). It can give precise pixel measurements and even code snippets for CSS or other layout code and export graphic assets. Once a design is set, it is handed off to the developer. At this point, the developer picks it up and builds the UI. Then it can go back to the designer for visual QA. Anything he finds wrong with it, should just be logged as a bug to be prioritized and resolved by you.

jiggy
  • 1,590
  • 11
  • 15
  • That does look interesting indeed. Too bad that they are somewhat expensive (especially since we make about 1 or 2 bucks a month on our projects, we are doing it just for fun), I'll definitely keep them in mind if we start making money (for some reason). – Finlay Roelofs May 19 '18 at 23:19
  • Zeplin is still free for one project. Sketch is $99/yr which is pretty modest. – jiggy May 28 '18 at 18:53
0

when something doesn't work out as intended (like for example, it didn't work out as we planned for some reason), I fix the issue on my side, then send him the template back

That's the root of your troubles. The flow of design should always be from Designer to Developer and never reversed. Revisions and changes should have been made by the designer, and then pushed to you for implementation in the website. You can always make fast fixes yourself, but try to accept that those fast fixes are just temporary. The designer needs to go back to his designs and figure out the proper solution. He then pushes the change to you, and if it happens to be the same as your quick fix then great, otherwise you update from his designs.

He sends the complete template to me (the HTML export from Pinegrow)

Don't become addicted to receiving HTML you can work with. It's better if you implement the website technology (Bootstrap, CSS, jQuery, React, PHP, etc.. etc.. etc..) the way you need it. You then reproduce his designs using those tools. If the HTML he gives you is a quick start then great, but later as the project grows it won't be of much use. You'll need to make the changes yourself because only you understand your templating engine (i.e. CakePHP views, templates, plugins, component, etc.. etc..)

This process, as one could imagine is painstakingly slow and inefficient.

It's always been that way. Designers aren't programmers. They take their time to figure out what works best for the user, and sometimes they make mistakes. They don't understand concepts like components, frameworks and such. As the programmer you have to speak to your designer and share the how I implement what you design.

The designer is stuck in the middle. On one side they must please the needs of the programmer, and on the other side they must please the needs of user.

So my question is, how can we make this process go smoother?

I've found that physically sitting beside the designer and programming there really helps with the communication. If you two are working remotely, then keep facetime running for a few days. It really helps speed things up.

I've seen a lot of stuff about that we should use React and use RESTful and what not, but we want to use CakePHP for it.

CakePHP is one of the best frameworks on the planet (full disclosure, I'm on the CakePHP core team).

Cake is a rabbit development framework where the features are designed to build websites quickly. I know that sounds like a sales pitch, but this is what it is classified as. There are many other frameworks that are classified as rabbit. Java would be an example of a framework that is more enterprise than rabbit. If you were using that language, then I would have made a recommendation to change. Since you're using CakePHP. I would argue you should stay with it.

CakePHP makes for a good back-end server if you need RESTful APIs.

React/Angular/Vue are all popular and trending front-end frameworks, but they haven't been around for very long. CakePHP on the other hand has been around for 13+ years. My point isn't a criticism. It's the fact that these JavaScript libraries have a short shelf life. In 5 years we'll all be talking about something new, but I suspect CakePHP will still be around.

So I say. Use React/Angular/Vue now while their hot, but don't get to committed to them. Something new and better will be along shortly. I think we live in a world now where you can't build good websites without them.

Could some people guide me to some helpful resources about it?

Requests for lists are off topic here. Sorry.

EDIT:

I missed the part about tracking design changes.

Have your designer save his HTML output in BitBucket (they have free private repositories). You can then track and do comparisons using the BitBucket website. Everytime the designer makes a major change he adds a new branch with a version number.

It should be relatively easy for him to do this, and this will allow you to have a place to comment on said changes. For example; he can make a pull request to update the repository where you perform a review of the changes before they are merged.

Reactgular
  • 13,040
  • 4
  • 48
  • 81
0

You need to separate these two things:

  1. UX & UI design, a non coding activity
  2. Implementation, definitely a coding activity

The designer should use creative tools like Marvel which are just for designing. It should not be designer's concern to do anything with code, HTML, CSS etc. The colors, dimensions, aesthetics, interactions, animations are all the things he should be focused on.

The programmer should receive the assets and the mock-up (with interactions and animations) and should make it happen by programming the software. This included HTML and CSS as well. The programmer can use generator tools on his side as well.

To speed up task flow, I recommend to use a minimal tool like Trello and link/document everything for each work unit.

S.D.
  • 957
  • 6
  • 16
0

how can we make this process go smoother?

Insist on version control

Software Branching and Parallel Universes

  • Work on no code not in version control. full stop. And I mean go on strike until the project is all in a VCS.
  • Branch formally, liberally, locally
    • Formally: branching for releases and sub-parts of releases, formal testing fix, etc. Evolve a formal version control plan, i.e. write it down.
    • Liberally: Beyond 4-part formal release numbering, branch if your gut tells you it might be a good idea.
    • Locally: I kept a personal repo with branches never intended for team consumption because as a team we did not branch at first, and I often have experiments, exploration, just in case, etc.

Engineer the hell out of your middleware APIs

Benefits:

  • Stability - even when the underlying code is evolving.
  • Testable code
  • Re-use
  • A team communication tool
  • It's a contract. A promise of services rendered (pun intended)
  • Coding in the realm of SOLID == happy maintenance programmer

It's the ask, don't tell principle applied in the obsessive compulsive way it should be. If the UI is manipulating a single business layer property, that's wrong.

Everything and anything about the business objects must be in said BO's. Even trivial things that may seem best done in the UI - even a single LOC. Minuita like adding 2 user-supplied values - all associated logic including validation must be in the business layer API. IMO redundancy is sometimes OK. To mitigate redundancy maybe have small, focused business layer objects that the UI is allowed full access to.

Everything and anything the UI needs from the business objects should be API'ed. For example have explicit methods that wire its argument(s) to event handlers.

Beware of frameworks as a crutch

In the hands of the unskilled, frameworks and IDEs are not barriers to the B-movie monsters they create.

With frameworks like React you might say it's all client side, there is no back end business logic layer. The key idea here is decoupling what the user sees from what the program does. That's doable. It's not just a physical server vs users' browser thing.

radarbob
  • 5,808
  • 18
  • 31
-3

I think it’s a good indicator of the immaturity out of profession and practice that we accept that people who design, cannot do.

This would not be acceptable in nearly any other profession.

It’s reasonable to expect a designer who specializes in web site/app design to know CSS and HTML well enough to provide you with working and usable files of that type.

Designer who provide WYSIWYG graphical editors are visual or graphic designers. There are many different kinds of designers.

However there also many different kinds of skills levels, abilities, and experiences. One who designs furniture could do it solely on a computer with 3D design tools, in which case their knowledge of how to turn a lathe or operate a CNC router might be wholly theoretical. They do their designs and then send them off to be made by others.

Conversely some expert designers may have control over the entire process and have the ability and knowledge to build their furniture with an eye to every detail, perhaps even hand-craft.

You will not be able to convince your friend to change their way of working. If you would rather have a web designer with the HTML and CSS skills to build their own designs, you will need to find one.

RibaldEddie
  • 3,168
  • 1
  • 15
  • 17
  • Downvotes are hilarious. I guess this is some kind of sacred cow? – RibaldEddie May 19 '18 at 19:47
  • Thing is,the files that he delivers to me are completely workable HTML and CSS files, but I have to search for the changes (easily done with a diff tool) and then manually implement them the way we wanted to. – Finlay Roelofs May 19 '18 at 20:41
  • @FinlayRoelofs what do you mean by “the way we wanted to”? Why not then talk to the designer and ask them to write the design as the team desires? A professional should be able to learn and adopt the practices of the team. – RibaldEddie May 19 '18 at 20:43
  • We are just a 2 man team. We come up with something (like for example, we want a page to have all our products in a showcase) and together we make plans on what we want in it and what it should do. He then designs the thing in his software (in the meantime, I'm either cleaning up what I already made or go fix issues). Once he's done, he send the template to me after which I do my thing (make it actually do something). – Finlay Roelofs May 19 '18 at 20:47
  • @FinlayRoelofs I’m confused then. Sorry. Either you need to accept that you’re just a two person team and decide how much time you want to spend on rewriting or accept the quality of what they deliver. – RibaldEddie May 19 '18 at 20:49
  • there is no "they", it's just us. the 2 of us are the only ones who have to do with the project (and the people that decide to use the service we make). – Finlay Roelofs May 19 '18 at 20:53
  • @FinlayRoelofs then fire him. – RibaldEddie May 19 '18 at 20:54
  • Why would I fire him? He's my friend (we decided to do these projects together) – Finlay Roelofs May 19 '18 at 21:02