Front end design to be handed over to a developer.

[Thor]

I'd like to understand better what would be required if I where to work in a team of front end devs and backend devs.

Ie, what "techniques" and/or principles must I adhere to in order to hand my front end work over to a developer and let him do his magic.

Right now I'm a wild cowboy but lately I've been on a self training mission and it's going very very good to be honest thanks to everyone's help on and off the forum.

 

[froot]

Look at human-computer interaction.
Application of the correct principles of user interface design is important tooo.
It's not a quick 2 page document though, there are lots of principles to consider.

 

[rward]

Hrrrn?

As in you have done the designs and now want the FE dev to code them up?

In that case, well named and layered PSD's, image assets (png's, svg's, etc) and some notes on how you want it all to work - should the header be fixed to the top of the page when scrolling? Should all sections be responsive or should some of them have a max width, etc.

Menu dropdowns - should they be instant, shoudl there be an effect (slow slide down), all that kind of jazz.


To be working as part of a team of devs you need source control, you need a ticketing system so you're not all working on the same thing. Some procedure on how you're going to work (branch per ticket, pull requests back to be peer reviewed, etc). A common coding standard so your code doesn't look like a patchwork blanket.

 

[Thor]

Hrrrn?

As in you have done the designs and now want the FE dev to code them up?

In that case, well named and layered PSD's, image assets (png's, svg's, etc) and some notes on how you want it all to work - should the header be fixed to the top of the page when scrolling? Should all sections be responsive or should some of them have a max width, etc.

Menu dropdowns - should they be instant, shoudl there be an effect (slow slide down), all that kind of jazz.


To be working as part of a team of devs you need source control, you need a ticketing system so you're not all working on the same thing. Some procedure on how you're going to work (branch per ticket, pull requests back to be peer reviewed, etc). A common coding standard so your code doesn't look like a patchwork blanket.

I build the site

I'm quite comfortable with front end.

But my backend ie functional development is lacking so I'd like to focus on being a front end developer one day

 

[rward]

I'd like to focus on being a front end developer one day

I'd like to understand better what would be required if I where to work in a team of front end devs and backend devs.

Ie, what "techniques" and/or principles must I adhere to in order to hand my front end work over to a developer and let him do his magic.

I think you need to start phrasing your questions better.

In your initial post you're asking "what "techniques" and/or principles must I adhere to in order to hand my front end work over to a developer and let him do his magic"

and in this last one you're saying that you are the front end dev.

What are you asking?

 

[_kabal_]

Sketch and zeplin

 

[Thor]

I think you need to start phrasing your questions better.

In your initial post you're asking "what "techniques" and/or principles must I adhere to in order to hand my front end work over to a developer and let him do his magic"

and in this last one you're saying that you are the front end dev.

What are you asking?

Working in that team as a frontend developer.

I thought that was implied after all my threads about sass, AngularjS, git etc.

 

[DA-LION-619]

It must be hard to do the front end without any mock data?

 

[skimread]

Static html pages or get the data via hardcoded json

 

[Thor]

It must be hard to do the front end without any mock data?

I make my own.

Like "Signed in" text etc as placeholders

 

[rward]

Working in that team as a frontend developer.

I thought that was implied after all my threads about sass, AngularjS, git etc.

My apologies,I misread the whole thing. You want to hand over your fronted work to a Backend dev

 

[DA-LION-619]

Static html pages or get the data via hardcoded json

I make my own.

Like "Signed in" text etc as placeholders

This is what I meant, I think you would be working with wireframes so the backend dev should have created the api's and you'd just have to fill them in?
Unless you're letting the backend dev fill in the blanks in your front-end work.

 

[Thor]

My apologies,I misread the whole thing. You want to hand over your fronted work to a Backend dev

Yes sir that is what I'd like to end up doing in the near future.

This is what I meant, I think you would be working with wireframes so the backend dev should have created the api's and you'd just have to fill them in?
Unless you're letting the backend dev fill in the blanks in your front-end work.

That's my question, what is the preferred methods here?

Do guys generally hand over the entire frontend to the dev to fill the gaps or does the dev create shortcodes that I pull into the frontend or or or.

That's what I'd like to know, I want to be the best front end dev a team can ask for in regards to the approach I implement to make the work easy for those taking the projects over after me ie the backend devs that bring the thing to life.

 

[FarligOpptreden]

Ideally, you'll have the UX team and server team working in parallel. That's why it's important to architect a solution first before jumping in and just building "stuff". You need a clear seperation of concerns and ideally follow a lightweight service oriented approach.

For each feature or use case, you'll need to define the entry points to the server (API's) and what type of content will be consumed and produced (HTML, JSON, SOAP, XML, etc), and that's where REST becomes your friend in helping you structure clear, easy to use services. Once those points have been identified, a wireframe of the architecture can be created and both back- and front-end developers know when and how to transact with each other.

Unfortunately you can't just build the front-end and expect the rest of the team to perform magic. You'll end up with a sloppy solution full of hacks and code rot. It's best to understand that you are a team and you're working towards a common goal.

 

[IndigoIdentity]

I think it's not very easy to just slip into a position like that either. In the cases where this is applicable it is dealt with by an in-house team.

Sure there are quite a few consultancies and agencies about but in my own experience you need a large amount of working experience along with a group of people that you can gel with you in order to be able to work things out properly. You need a fair amount of time to dedicate to this these options too. The potential to fit in drops when you take that into consideration.

Then there is the market of templates. You could always build some stuff that would fit on wrapbootstrap and I do not think that it would be very hard to accomplish something like this. Referring to something like an admin template which could be more complicated, seen a few popular ones with Angular implementations. Many use Ajax and provide some sample data in json files.

Whichever way, if you have a front end template and you want to know if it's missing something then why not show some pictures or put a demo online. Then we might be able to say hey wait but you still need X or Y could be improved on because of ___. Etc.

Edit: Thinking about it now... If you want to learn about current techniques when it comes to this kind of thing then http://wrapbootstrap.com/ would be a good start. View some of the new templates, view the source. look for common functionality, look at how mock data is implemented, buy some popular ones and see how the documentation was done and how they were put together and packaged?

 

[kripstoe]

Nothing beats sitting next to a UX person while developing. Each role knows what is possible within the time and budget. The difference in perspectives is also very helpful.

 

[zippy]

Its an iterative process and you work in parallel. Sometimes the back end work is started first and then tweaked to get the api working for the front end. It depends on each project.

 

["Clark Kent"]

I prefer the front to back way. It's cleaner.

 

[DA-LION-619]

I prefer the front to back way. It's cleaner.

Do the front-end then back-end?

 

[rward]

An off the cuff process that could be used:

Speak to client and get the requirements (lots more to it but that's the gist).
Turn the conversation into deliverables
Spec out the backend
Spec out the frontend
Ensure the backend can accomidate/deliver what the frontend needs
Figure out the technology to use

From here you should have something like:
Backend:
Endpoint: /api/order/:id
Description: provides the Order information for the specified id
Output Fields:
order id
order date
order description
order yyy


Frontend you could have a wireframe like:

Order #{order.id} Date: #{order.date}

Description: {order.description}


Now you can code up the frontend knowing that the backend will be able to support what you're doing.

As skimread said, you can mockup some json structure to test your stuff. When you connect it up to the backend then you remove the mockup data and plug it into the backend and it should work as expected.