SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 89
  1. #26
    SitePoint Wizard bronze trophy Kailash Badu's Avatar
    Join Date
    Nov 2005
    Posts
    2,561
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am primarily a developer and write backend serve-side code more often than I do CSS/HTML.
    Well, I might not need to know the frontend before being able to write classes and generic functions but I do need a basic interface and page structure in place before I can write the code that is responsible for generating web pages. It generally tends to be a minimal interface, however, which can then be replaced with a full-fledged design once the backend is over. Keeping view logic separate from business logic eases the task of editing/replacing design enormously.

    In some projects front-end and backend go hand-in hand. I keep updating the interface as I add more functionality in the backend.

  2. #27
    is craving 'the potato' slayerment's Avatar
    Join Date
    Nov 2002
    Location
    Scottsdale, Arizona, USA
    Posts
    604
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the development should come first and the design should come last. The design is something that should be tweaked and tested for conversions and therefore will always be changed and improved, but the backend will change much less.

  3. #28
    SitePoint Guru Dijup's Avatar
    Join Date
    Jun 2006
    Location
    Kathmandu, Nepal
    Posts
    790
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by slayerment View Post
    I think the development should come first and the design should come last. The design is something that should be tweaked and tested for conversions and therefore will always be changed and improved, but the backend will change much less.
    I think it is better to have the design of the project [either UI or logical design] Ui come first because ever project is made for the user so UI should be there so that we can target our plan according to that.

  4. #29
    SitePoint Guru Dijup's Avatar
    Join Date
    Jun 2006
    Location
    Kathmandu, Nepal
    Posts
    790
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Nick Burd View Post
    Personally here is my method.

    1. Draw and design the sites appearance.
    2. make a site map along with a database map...
    3. start developing the basics of the site
    4. start developing the "dynamics" of the site and integrate them as you would for a database driven website.

    for the planning stage for the db I like to use mysql workbench.. pretty much plans it all out for you or allows you to do so.

    here is the link http://dev.mysql.com/workbench/

    Sound like a good plan?
    Sound Good!

  5. #30
    SitePoint Addict
    Join Date
    Apr 2005
    Posts
    274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The thing that I noticed back when I was working with clients was that clients don't really know what they want.

    This is why I make designs first. Then code HTML files so that we can see what the design/functionality will look like in a regular screen (this is before doing any backend coding). Every client's initial design has changed dramatically, and with design changes there have also been numerous functionality changes. If we started with coding or started coding only after the initial design, a lot of coding time would have been wasted, and then ending could would probably be of poor quality due to all the changes it would have to undergo.

  6. #31
    SitePoint Wizard
    Join Date
    Mar 2008
    Location
    United Kingdom
    Posts
    1,285
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I always plan the entire site out on paper, using a site map and just scribbling.
    Then design an idea for the layout(because I'm not great at it, I like to get it out the way!)
    Then develop it as I feel more adept at this part and enjoy it most

    Then revise all 3 areas 'til the client and I are chuffed

  7. #32
    SitePoint Member Zanicar's Avatar
    Join Date
    Aug 2006
    Location
    Pretoria, South Africa
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have noticed that no one made a distiction between interface design and interaction design, I mention this because I am of the opinion that interaction design is a sub-set of the interface design.

    For most people the interface design involves the full front end, namely images, backgrounds, mouse-overs, etc. Interaction design leaves most of these out by stripping the interface down to interaction elements. These are simply the text, links, buttons, etc. needed by the user to do what needs to be done.

    Coming from a systems engineering background I prefer to do the interaction design first (use-case analysis). So I start with the XHTML as my interface and create a mockup in Photoshop. Then I develop the back end and test to ensure the interface is easy to use even without the aid of any graphics, images or effects. Lastly I integrate the mockup into the interface with CSS.

    The major advantage of this approach is that all my sites and applications work on mobile devices by default, I do not need to change anything for it to work... I only have to optimize my graphics for smaller screen sizes.

  8. #33
    SitePoint Guru Dijup's Avatar
    Join Date
    Jun 2006
    Location
    Kathmandu, Nepal
    Posts
    790
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Zanicar View Post
    I have noticed that no one made a distiction between interface design and interaction design, I mention this because I am of the opinion that interaction design is a sub-set of the interface design.

    For most people the interface design involves the full front end, namely images, backgrounds, mouse-overs, etc. Interaction design leaves most of these out by stripping the interface down to interaction elements. These are simply the text, links, buttons, etc. needed by the user to do what needs to be done.

    Coming from a systems engineering background I prefer to do the interaction design first (use-case analysis). So I start with the XHTML as my interface and create a mockup in Photoshop. Then I develop the back end and test to ensure the interface is easy to use even without the aid of any graphics, images or effects. Lastly I integrate the mockup into the interface with CSS.

    The major advantage of this approach is that all my sites and applications work on mobile devices by default, I do not need to change anything for it to work... I only have to optimize my graphics for smaller screen sizes.
    I think you missed out the topic.

    design or develop first?

  9. #34
    SitePoint Enthusiast
    Join Date
    Jul 2008
    Posts
    33
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    first design in mind .Then according to your design,develop your site .After the development completed .Start to design your site according to your mind design .

  10. #35
    SitePoint Member Zanicar's Avatar
    Join Date
    Aug 2006
    Location
    Pretoria, South Africa
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dijup View Post
    I think you missed out the topic.

    design or develop first?
    Design interaction first, then develop, then integrate with any graphics design (done before or after... consider CSS Zen Garden as an example)
    Technology Management
    Cloud Computing Systems
    Rich Internet Applications
    http://noctranet.com

  11. #36
    SitePoint Guru Dijup's Avatar
    Join Date
    Jun 2006
    Location
    Kathmandu, Nepal
    Posts
    790
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Nick Burd View Post
    Method.
    1. Draw and design the sites appearance.
    2. make a site map along with a database map...
    3. start developing the basics of the site
    4. start developing the "dynamics" of the site and integrate them as you would for a database driven website.
    this is the some what solution what i think for this question

  12. #37
    SitePoint Addict Fre420's Avatar
    Join Date
    Nov 2005
    Location
    Leuven, Belgium
    Posts
    211
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1. develop a website strategy: get to know the company, the targetgroups, the goals, plan the metrics to measure the goals, develop persona's, ...
    2. wireframing the basic information architecture (paper)
    3. storyboarding: filling in the wireframe with persuasive copy & interactions (paper & prototype software (axure, visio) )
    4. prototypes: from a paper wireframe to a simple HTML mockup, adding design details (from black & white design, to grayscale, to color ...). Basic interactions with javascript tests (or just in html). --> end result fully working HTML template (90% of design laid out, most of the html & classes won't change, every positioning property of the CSS is +- done, crossbrowser tested)
    5. development & final design: finalize the design with details & finished images, finalize the CSS & HTML. start developing the back-end & database.
    6. during the comming months/year : optimization, improve the website based on your metrics & goals, & user behavior on your site. (you never get it 100% right from the first time)


    during wireframing --> development & final design : testing & testing & testing
    with the persona's (try to get them accomplish their task) or small user tests.

  13. #38
    SitePoint Enthusiast Rblakney's Avatar
    Join Date
    Jul 2008
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I usually design first.

  14. #39
    SitePoint Addict dgroves's Avatar
    Join Date
    Jan 2007
    Location
    Bath, UK
    Posts
    364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I tend to be torn between the two ways, I love design but I am c**p at coming up with ideas. I always have awesomely complicated ideas for the back-end, but hey I soon lose all motivation without the design. If I do design first then I am sick of my design, and want a redesign by the time I have finished! So what am I to do?

  15. #40
    SitePoint Enthusiast
    Join Date
    Dec 2007
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First do the backend including database design, coding and debugging after that do the graphics works. It is the proper way for a developer. I go this way because basically I am a programmer.

  16. #41
    Jewish Juggernaut mkoenig's Avatar
    Join Date
    Aug 2007
    Posts
    1,227
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by neron-fx View Post
    I personally stick to these 18 golden rules and work like this in everything that I do (skipping any steps that aren't relevant to a project). To some this would seem anal but I am just very very particular and like to ensure that there are minimal things to go wrong on launch.

    You will notice that I leave all designing, CSS and visual testing until last. This is due to the fact that durig development I am often asked to add extra features or more UI elements to the app, and so dont want to waste time messing around in Photoshop everytime the client adds in an extra drop down. I prefer to do it last when all the functionality is in and working and I can just lay my styles around everything else (I seperate all logic from styles anyway so its actually easier.)

    1. Database Design and Architecture - On paper
    2. App Design i.e. flow, actions, plans for functionality - On paper
    3. Setup Dev and production environments
    4. Create Database - On Dev
    5. Write all core logic and functionality - On Dev
    6. Write all testing units to test every piece of logic and functionality - On Dev
    7. Test and Debug in all browsers -On Dev
    8. Upload to production servers but make inaccessible to public
    9. Test and Debug in all browsers on Production Servers
    10. Create Designs and Concepts in Photoshop
    11. Create, slice up and optimise all graphics
    12. Write CSS, Make sure all XHTML and CSS is standards compliant and accessible - On Dev
    13. Test again on Dev but this time for visuals (all browsers 800x600 - 1280x1024 resolutions)
    14. Migrate to live servers (again not accessible to the public)
    15. Test visuals on live servers
    16. Migrate fully to live servers (allow access to 5 people for User Active Testing
    17. Fix all bugs found and make amends given
    18. Launch to the public.
    Wow... thats pretty intensive.

    I think you should get the backend working before worrying about what the site ultimately will look like. If you get the design going then start working on the backend and run into problems you either can't overcome or can't afford someone to overcome for you you've wasted a lot of good time.

  17. #42
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,576
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Really, really depends on what the application is doing first. Personally, I prefer to design and build the logical domain then bolt a user interface on top of it. Building the back-end around a specific UI is generally an exercise in folly in non-trivial applications.

  18. #43
    SitePoint Addict
    Join Date
    Apr 2005
    Posts
    274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99 View Post
    Really, really depends on what the application is doing first. Personally, I prefer to design and build the logical domain then bolt a user interface on top of it. Building the back-end around a specific UI is generally an exercise in folly in non-trivial applications.
    I agree, but if we're talking about web stuff, you'd be hard pressed to find a non-trivial application.

  19. #44
    SitePoint Addict NetNerd85's Avatar
    Join Date
    Aug 2005
    Location
    Australia
    Posts
    298
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by neron-fx View Post
    I personally stick to these 18 golden rules and work like this in everything that I do (skipping any steps that aren't relevant to a project). To some this would seem anal but I am just very very particular and like to ensure that there are minimal things to go wrong on launch.

    You will notice that I leave all designing, CSS and visual testing until last. This is due to the fact that durig development I am often asked to add extra features or more UI elements to the app, and so dont want to waste time messing around in Photoshop everytime the client adds in an extra drop down. I prefer to do it last when all the functionality is in and working and I can just lay my styles around everything else (I seperate all logic from styles anyway so its actually easier.)

    1. Database Design and Architecture - On paper
    2. App Design i.e. flow, actions, plans for functionality - On paper
    3. Setup Dev and production environments
    4. Create Database - On Dev
    5. Write all core logic and functionality - On Dev
    6. Write all testing units to test every piece of logic and functionality - On Dev
    7. Test and Debug in all browsers -On Dev
    8. Upload to production servers but make inaccessible to public
    9. Test and Debug in all browsers on Production Servers
    10. Create Designs and Concepts in Photoshop
    11. Create, slice up and optimise all graphics
    12. Write CSS, Make sure all XHTML and CSS is standards compliant and accessible - On Dev
    13. Test again on Dev but this time for visuals (all browsers 800x600 - 1280x1024 resolutions)
    14. Migrate to live servers (again not accessible to the public)
    15. Test visuals on live servers
    16. Migrate fully to live servers (allow access to 5 people for User Active Testing
    17. Fix all bugs found and make amends given
    18. Launch to the public.
    This is brilliant and have to agree with the pure logic of this process. If you don't nail down the HTML wireframes (website without CSS or graphics) and the functionality then you will get feature creep. As someone who works in a web development company I see them make this mistake all the time (I have experience with another company as a Team Leader so I've seen it all before). In my spare time I develop things for myself - so I am the client and users. It is very easy to keep adding to a project if you don't have the discipline or the balls to stand up to a client (most people don't which is frustrating). I constantly have to re-do things for clients because of communication break downs and poor project management, it's called a PHASED process people

    Great process neron-fx it's basically what I do too, I'm going to print it out now and pin up on my wall. I need it in my face as I have three new projects on the go got to stay focused.

    People should, no, must read Getting Real
    a new day, a new beginning
    never follow the crowd, the crowd is poor!

  20. #45
    SitePoint Zealot
    Join Date
    May 2007
    Posts
    163
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I faced the same dilemma recently,and was
    going nowhere with the project untill I got a
    brainwave-DO THE BACKEND FIRST,THEN THINK
    OF/FIND A DESIGN TO FIT.And i'm happy with that.
    I think its because i'm better at coding.Though i
    already have the whole concept(interface) in mind.
    So,i think you should start with what you do better/
    find easier/happier with,having a sketch of the whole
    concept in mind or paper.
    Generally,i think codes are more flexible-it is easier to
    adapt codes to whatever design than do the opposite.
    So it might be better to do the backend first.

  21. #46
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,016
    Mentioned
    53 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Edman View Post
    I agree, but if we're talking about web stuff, you'd be hard pressed to find a non-trivial application.
    so you're saying it's easy to find trivial web applications, but difficult for find non-trivial ones?

    i disagree!!!

    r937.com | rudy.ca | Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  22. #47
    SitePoint Addict dgroves's Avatar
    Join Date
    Jan 2007
    Location
    Bath, UK
    Posts
    364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Although I am primarily a designer, I think it is important to the back-end first. How can you design a layout for something before you have something to put into the layout? Something may go wrong and then you end-up having to make major changes to compensate for these changes.

  23. #48
    SitePoint Enthusiast mexabet's Avatar
    Join Date
    Jul 2008
    Location
    mexabet.biz
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Since I started out as a designer, I naturally tend to design first and develop later. But lately I've been having difficulties- having to go back and change a lot of time-consuming design layout. So now, I'm gravitating towards developing first.
    The Best Is Yet To Come!

  24. #49
    Non-Member
    Join Date
    Jan 2004
    Location
    Seattle
    Posts
    4,328
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by NetNerd85 View Post
    This is brilliant and have to agree with the pure logic of this process. If you don't nail down the HTML wireframes (website without CSS or graphics) ...
    Is that the definition of a wireframe - a website sans CSS and graphics? I never really noticed that term until I was checking out some jobs just a couple days ago. The context suggested it refers to sort of a website blueprint.

  25. #50
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,016
    Mentioned
    53 Post(s)
    Tagged
    2 Thread(s)
    yes, exactly like a website blueprint, except without the blue and without the print
    r937.com | rudy.ca | Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •