Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Web development is a mess.
This is because we have to interact with a lot of people.
Businness, Designers, Developpers, Leads, etc...
A website is a mixture of a lot of skills which involves programmers, designers, seo experts, business persons, ergonomists, etc...
So, the question is, how do you work to make all those people understand themselves, interact together.
How could I decompose the severals steps leading to a website ?
Because a lot of enterprise sales a design at first, how could you then add the right functionnalities ?
For example, we can decompose a project like this :
Functional scopes (CRUD, Resources, ACL)
Designing the interface
Start development
Write xhtml/css according to the interface with the functionnal requirements
I may have forgotten steps, or disordered them.
EDIT :
For example, here is how I do :
I write a short overview about the project, what is the main goal ?
I try to know which resources (users, articles, products, etc..) are involved.
I write a short CRUD list for each resources which help me to have an overview about the features
I start to design the database (with mysql Workbench for example)
That done, i try to know if there are roles and privileges to rely them with the resources
I start development (+ testing)
Then i insert xhmtml code to respect W3C & web semantic.
I start to insert visual design with CSS
So what about you ? what are you steps to be efficient ?
I would say:
Overall Site Intent
User Analysis (Determine site/application Demographics, User Groups, etc.)
Conceptual Design
Graphic Design
Functional Scope
Interface Design (Prototype, Wireframes, etc.)
Interface Mockups
Development/Unit Testing
User Acceptance Testing
...pick and choose the parts you need. Doing all of them may be overkill, but probably not if you're working on a large team with many groups giving their input. Making sure you don't miss steps gives a chance for everybody to give their input and decide on a course of action.
Web development is different from other types of software development because frequently
there aren't any users among the development personnel. For example, "users" are absent from your list of people involved.
The users exist as a notional bunch of faceless people who are out there (we hope, because that's what the business plan is predicated on). Requirements are gathered and design decisions taken on the basis of assumptions about what the putative users might like or want.
So in many ways web development more resembles opening a restaurant or launching a new political party than rolling out an ERP system.
I don't think there's actually anything unique about web-development here compared to regular software development (with the exception of seo, which is just another technical challenge). I don't think there's anything inherently more "messy" about web-development. Read through the terms in your question again - do any of the terms (excluding seo as mentioned) not apply to general software development (substitute "xhtml/css" for "frontend development")?
Personally, I think any software engineering methodology which you've found works for your team-size/work environment/colleagues/etc is applicable to web-development.
There's nothing magical about the fact that the end-product runs in a browser.
XP and Agile methodologies look at creating teams whose members have all the skills needed for the project, such as Project Manager, developer, business anylist, designer, tester etc.
Having teams means there is better comunication between everyone involed including the client.
The subject is massive so do some google searches on XP, agie, scrum, kanban.
Yup dear you are right, there are several steps in developing a dynamic website however you want to develop a static site then its easy.
the only designing is needed for it and some functionality is added by a designer like email and so on.
but if you are going to develop a dynamic website then its accomplished by these steps.
1. First you make sure about the requirement.
2. Then you decide about its interface and layout.
3. Designer designed all the Form the are needed
4. Then the developer./ programmers will add functionality on froms .
5. After Completing the coding part the project goes to Testing for erros.
6.if any error occurs then it rectified by programmer again it goes to testing this process will going on until all error has not been removed.
7. Finally the web site publishes and then hosted on a server.
A website is a mixture of a lot of skills which involves programmers, designers, seo experts, business persons, ergonomists, etc...
If you're really lucky you will have a team of talented multidisciplinarians who can take on more than one role.
That's when you tend to get the best web products.
Design by committee, which you will always get if everyone only gets to 'wear one hat', rarely produces kick-arse products.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have to design and develop stand alone desktop application using NetBeans , Java and MySQL. I need to know how to plan my software step by step before coding, like create SRS document, drawing use cases, plan ER Diagram, Flow charts , BP Diagrams, Class Diagrams, etc...
complete quality product with less errors
As per my understanding, the development model needs to be determined - if it is waterfall or prototypical. Waterfall model is not much in use these days as per my knowledge. Under waterfall model, the coding begins only after the requirements specifications and software design is fully developed and nailed down such that there is almost negligible chance that they would change. However, in modern world, the agile or prototypical software development model is being followed where we start with basic requirements and basic software design and then directly proceed to coding, testing and also sometimes releasing the product as soon as possible. And then all the steps of srs, design, coding, testing and releasing get repeated continously until the application's life time, thus the product gets better with each release and only after few releases it will reach at a point where it has got many features live in production.
The reason that the iterative model of software development is more popular is because the requirements keep changing and it is hard to nail down the requirements for all the features of the product beforehand because the stakeholders don't have the full idea of what they want and/or how they want. The same is true for design, due to change in requirements, the software design also needs to be changed and hence it is not beneficial to lock down the software design either.
However that being said, it is not the case that iterative development does not have any srs or any design specs. I would suggest to start with basic srs and basic software design that captures the very core part of the application and also keep it flexible so that it can accommodate the changes easily.
The diagrams and documents that you mentioned are all good starting points. However, they need to be kept at minimal capturing only the core part of the application so that the coding, testing and releasing part can proceed quickly and thus accomplish the goal of getting that initial version (proof of concept) out so that it can be demonstrated to the stakeholders.
Let us say, it is a shopping application, the core part of it may have these features:
Ability to add items to inventory
Ability to show all the items to user (search comes later, user authentication comes later)
Ability for a user to view details of the item
Ability to make a purchase (fake purchase, actual payment processing can be done later)
Ability to view the orders and order details.
Thus the above features try to complete the critical path of the application so that it can be a working application as soon as possible and can be demonstrated and iterated over. The features that are not critical initially can be stubbed out - such as authentication, search, payment processing, sending emails and so on.
I am not sure if this answers your question but hope it provides some pointers in order to start the application development from scratch.
If you have more time then follow waterfall model.
You can go for Agile methodology for fast delivery of application.
Planning of software depends on following factors
1)scope of project
2)deadlines of project
3)Number of resources available
4)cost of project
5)R&D work time etc
i hope , it will help you
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
We outsourced a web based portal and now we're not interested to work with them because the site is becoming more buggy day by day and increase of customers complain.
We've chosen a different team based on their local reputation and their portfolio are good to satisfy our urgent needs. We discussed this project with them and during a week they suggested some good ideas which help us to control. We are agreed to award this project to them. What I am thinking during the transition:
What documents do you think which can help new developers to understand the application? How many kinds of document I can request to them? If a new developers start working on it those documents help them to understand easily of all sides (application, database, configuration etc)
The application is on ASP.NET and SQL SERVER 2005 and the scariest part of all no source control tool is there. They do direct deployments without even push the publish button. Touch Luck :(
Thanks.
That's kind of hard to answer without knowing what kind of portal it is, but what comes to mind:
Owner's manual: Description of functionality, technologies used, full overview of all machines and services involved (don't forget data bases)
Backup: How and where is data backed up, where to restore it from in case of a crash
Description of all Databases used, relations between tables, at least quick rundown on what data is stored where
Links to any and all URLs to administration interfaces, tools, and scripts
Day-to-day operation: What cron jobs need to run frequently, are there caches, file lists or other things that need to be taken care of frequently
Make sure all domains used belong to you and are under your control
a description of the project's file structure (which part is where; where is the API; where are the visual elements; where are the front controllers)
How-To's on how to change the visual elements of the site (Style sheets, forms, templates...)
A description of any and all URL rewriting operations that take place in various parts of the systems, and where they point to
Which Google Analytics / Google Webmaster account is used and how to get hold of it
Ideally, an API documentation and full phpDoc style source code documentation
In addition to #Pekka's good answer I'd add the following
Functional Design Document (or
Business Requirements) - One that
explains how the application should
work from a business perspective.
Technical Specification (or
Architecture document) - One that
explains how the application was
developed from a technical
perspective.
Application Support
Guide - Some form of cheat sheet that
explains the common problems, service
accounts, batch schedules... etc
In addition to documentation you should be aware of the incident trends;
How may incidents?
How often?
How long do they take to resolve?
How many known defects are there?
Who maintains the infrastructure (patching OS, security audits, etc)
If you don't have enough technical resources to cover the daily number of incidents (keeping in mind there might be peak periods when usage of the portal is high) then you will probably find yourself in the same situation as your current service provider.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are currently starting a bigger project. What're your suggestions for best practices of workflow?
We are planning to rebuild from scratch (the existing product is outdated by years, regarding visual and internal design and programming). While the product functions (a Rails based web project) are already set, the question is: What is your workflow from here on? The most interesting part is: How and when do you do your screen design?
We are planning to do it in the following order:
"Pencil and paper" screen design: Just layout what the screens should look like and visualize the functions and visitor pathes
Hand out the layouts from point 1 to the designers, have a talk to them, and let them work in parallel to programming on the designs
First implementation, simple color-less HTML layout based on point 1 (automated tests, functionality, BDD, TDD)
Integrate the designs with the product prototype
Work out the rough edges together with the designer team to finalize the product
Release a beta product for the customer to test
Do you have similar workflows? Are there suggestions for improvements? But the most important for me: How exactly do you do point 1?
While this is not exactly programming-related I still think this should belong on StackOverflow as this is important for anyone doing bigger projects. From the past we know that good screen design is always a critical and hard point if trying to do that while programming, and even harder to deploy it after the prototype application has been created.
Update: I found Balsamiq Mockups to be a very helpful tool to do the mockups. Still there's an open question how one would best visualize visitor pathes.
Update: We had been successful using Balsamiq Mockups to create a design pleasant to the customer and we managed to successfully integrate this into the existing web content. The customer is so comfortable with the new ideas that he is planning to redesign the complete web site.
I like your workflow. It should lead to a decent result.
A few ideas here:
Let the designers know and understand your presentation model. What pages there are, what information and control elements will they have, what is the role of each of them, what is the purpose of the page and what message should it communicate to the user. If you let the designers work alone then they will design something to reflect their vision of the project and not your design. You'll end up redoing everything or trying to adapt one part to the other.
Users will only see and understand design. They know nothing of implementation. If they see a button they will think the feature is there. if you plan to go agile while cooperating with the users during development, hide out elements that are not implemented yet. Feed them results one step at a time.
If you can have users nearby do screen design together with them in iterations. There is not much work for designers yet, when you are basically deciding on the layout. All those colourful effects and polished buttons should be done after the layout is stable. Otherwise it will be a waste of the designers work.
I really like the model of extreme programming. When dealing with new products user requirements can quickly change over time and this is a proven method which keeps the design "up to date".
Have the users write up functions that they want for the application. And have the designers agree upon a general layout.
Write up a general wire-frame that both you and the user agree upon, I like to do this in smart draw or some sort of rapid gui development platform. (no functionality at this point).
Write the code for the GUI based upon the wire-frame and write sequence diagrams and class diagrams.
Based upon these design start to fill in the functionality behind the GUI
Release betas throughout the process of adding functionality to select users who can help guide future development
The benefit of this design is that at any point in time you can re-work the GUI and incorporate new functionality. The idea is to have a general plan at the beginning that can be adapted as user requirements change.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In some software company, who should be responsible for the UI design:
User
Designer
Manager
Boss
Depends on company size
etc.
In UI design I mean not only colors and images, but also control's layout, count, size, style, may be text user see.
In a small company, the answer is "whoever is good at it". Some of our best graphics were designed by a technical author who happened to have a flair for graphic design. Don't assume that someone has to have the right job title to do a creative job - innate talent trumps a job title any day!
Most companies have GUI experts and who design the front end. Some even have altogether different person(s) in team for interface layer programming, leading to tools like Expression which are supposed to draw a line between both jobs.
It however depends completely on company/person developing the application.
Well, UI design should be a collaborative effort. You as a developer should provide technical suggestions as you know the system from the inside. Your boss does provide the final answer, but he/she can provide a different opinion that you may not have realized.
Usually though, the business partner decides the final UI. They have have the practical experience with whatever your program is going to solve. They sometimes know for a fact what the user wants and expects from a solution. The UI would be a lot friendlier if the developer and business partner collaborated on the design.
A dedicated UI person is valuable to a development team, but several roles should have involvement in UI development. Ideally a UI person should be able to bridge between designers and programmers, so that the final design can be implemented with minimal technical problems. UI should be reviewed with programmers to make sure it can be translated to the web (or whatever platform you're working on) and with business analysts to make sure all the requirements were accurately represented. Users should also be involved in the design process, since they can provide feedback on usability. Sometimes what you think is a great UI will fall flat because users don't understand certain features. I've never had a project manager get involved in UI, but every team is different.
As far as the skills of the person developing the UI - It's not unusual to find a graphic/web designer who has development experience, so they will be able to create the designs and integrate them into the application. Depending on the project size you may have different UI roles. One project I worked on had a graphic designer, a usability / 508 expert, and a "UI integrator" (basically a front end developer). If there is no money for UI people, I guess the task would fall to a developer. I've worked with programmers who claim they "don't do UI" and they won't even touch presentation code, but I think any programmer who works on a platform that has UI needs to be able to do front end work.
This is for the User Experience Team. They should have tested a design, copy (text) and all of the other stuff well before you see the design or final layout.
Depending on the technology, the UI will be designed either by a programmer or a graphical designer or both, based on scetches of the program owner, a product manager or the end user.
It will always be the user that accepts or declines and therefore decides on a user interface. Hopefully not after shipping by just ignoring the application or solution.
Ideally, someone with formal training in interface and interaction design should be the one designing the UI. Nowadays, this is a discipline in its own right, with its basis in (graphic) design, psychology, ergonomics, communication sciences, perhaps even software engineering, etc. This does not mean that this person is the only one that deals with the user interface, as various stakeholders may have influences:
The boss may enforce some decisions based on strategic choices or financial considerations
Marketing may enforce some decisions based on product management
The customer may have peculiar wishes that he demands get implemented
The developers may have a certain style or preference
Common UI element, specific icons, logos, etc. may be designed by a graphic designer
But ultimately, it should be the UI expert that combines all these inputs and designs the UI.
Of course in practice, it depends very much on the size of the software company. A very large company can have their own department for user interface / user experience issues, whereas in a small company, the task usually goes to whoever is deemed best at it.
In any size company, you can take the chain of command and move up, to see who has the last say, and the reverse holds true for who will do it.
In an ideal world the Presentation layer is the responsibility of the analysis and design team. There are a lot of theoretical and practical uses to a UI, which a simple designer may have never been taught. That does not go to say that a designer with a brain - or experience - will not generate more than adequate results.
Bottom line: there is no right answer for a design. Even if you have a checklist of things that a good UI should include, there is always the aesthetic aspect of it, which is not really quantitative.
No better approach than trial and error. Even Google Adsense/Analytics encourages you to make multiple designs, and alternate between them while collecting statistics which are quantitative.
Given your question, I am guessing you do not work in a large company, otherwise your job description would have been well defined.
So: Stop whining and just do it!
UI design is a joint responisbility. UI Design is not just a flair for graphic design
It involves the clients, users, some with flair for graphic design and developers. You even review the UI which is done by someone other than the designer & asking stack overflow users' thoughts on a specific design brings us into the equation.
Generally, all people are responsible and one or a couple of people should be involved in the process from first contact with the client to final delivery on the system.
communication skills, flair for design (lo-fi or hi-fi), objectivity, being able to take criticism and analytical ability are all required.
The extent of applying these skills will vary by company & project size.
Graphic design flair means you could possibly get a great looking UI that is not usable.
I agree that UI design is a collaborative effort. In my experience graphic designers or user interaction experts create great mockups which ultimately get bastardized by managers and developers. If you have a UI concept that you want to get added, make sure to justify every aspect of your design.
Here is a basic idea of how the UI evolves in my MASSIVE software company.
Managers dictate a 1 or 2 sentence requirement.
Dev team develops feature
Graphic designer comes up with UI based on managers crappy description
Dev team bastardizes the graphic designers UI
Management completely changes their mind
Repeat step 2-5 at least three times
Release a Beta
Beta users and product reviewers feedback drive the final UI
Do not underestimate a good beta. You could make all the graphic or user interaction designers in the world happy; ultimately it's the consumers that buy your product.
How a UI looks should be guided by the user interface design guidelines. If your organization doesn't have guidelines lines it would be great to start on one.
The UI Guidelines ideally should be put together by a Visual designer (Theme) with help from an Interaction designer (behavior). So the answer is what colors should be there are answered by the Visual designer and what it should/ shouldn't not do by an interaction designer.
In real world all kinds of roles have a say in the interface. What we call stakeholders. From strategy guys, to marketing people, down to project management people. The nest to quite them all is to prepare guidelines that direct.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm facing developing a new web app in the future and I'm wondering how to decide what framework to use. I've settled on Python as my language of choice. But there are still may frameworks to choose from! More generally how do you choose between different similar technologies that are still in the works as the latest round of web frameworks are? I'm curious what your process is for deciding on technologies you've never used.
Recognize that no choice is perfect -- or even very good.
No matter what you choose, someone will have a suggestion that -- they claim -- is better.
No matter what you choose, some part of your tech. stack will fail to live up to your expectations.
The most important thing is "shared nothing" so that the components can be replaced.
After that, the next most important thing is automatically-generated features to reduce or prevent programming.
Look at Django. Lots of automatic admin features make life very pleasant.
There are a number of things you can do:
Download the frameworks and build something similar with them for comparison.
Look for comparisons by other people, but attempt to understand the bias of the reviewer.
Observe the community at work, see what people are building and the issues they run into when using the technology. Forums, blogs, mailing list etc are good places to check out.
Go to conferences and meet like minded developers interested.
You can also take the approach of using stable versions rather than alpha bits. After a while you might move closer the bleeding edge. People associated with the project in question are generally more biased than those approaching from other platforms, be careful who you trust.
Consider the impact of using a bleeding edge framework versus an established one. Sometimes it's important to your customers that you are on one perceived as stable. At other times this doesn't matter. How comfortable are you with fixing the framework itself? Great developers will learn the internals, or at least know enough to keep things moving whilst a bug is sent to the framework mailing list etc.
Consider some general best practices in building abstractions and reusable code on the python platform. You may be able to save yourself some work in moving to another platform. However, don't be a reuse junkie as this can limit the effectiveness of your use of the framework. The 37Signals guys are right when they talk about extracting frameworks from working code rather than building frameworks from scratch.
I know this is an old posting, but I am in a similar situation (again) and I think there are other people who may want to look for different opinions, and hear of (somewhat) successful experiences.
Since baudtack mentioned Python, I will try to answer this along the lines of my experiences using Python. Here is what has been working for me:
determine the scope of your project - outlining what your application is supposed to be able to do without introducing any programming or design notes will clarify your goals greatly
determine how you would like to work with your code, stack and data:
a. what sort of programming paradigm do you want to work with? i.e. object-oriented, functional, etc. do you want to play to your programming style or do you want to follow somebody else's programming style?
b. use semantic web or not? do you want greater control over URIs and their design? (I found web.py great for this by the way - It is my choice to create REST APIs in Python)
c. do you want to be trapped by framework requirements, or do you want a better separation of the application from the web component, i.e. use a framework to utilize your application as a set of modules, for example. My problem with Django was that I ended up not programming Python, but having to learn more Django than I needed to. If that works for you, then that is the way to go.
d. data stores... some sort of SQL vs. non RDBMS (xml databases like eXist-db with full xquery support) vs. OODBMS vs. a combination of the above? how complicated do you need this to be? how much control/separation do you need to have over how data gets stored and recalled in your application?
e. testing: unit tests... thank goodness for python! if your web app has the potential to grow (as they often do), having a sane and coherent testing platform to begin with will help out a lot in the future - I wish I had learned about this earlier on. oh well... better late than never.
f. how much control over the server do you need? hosting considerations? how much control over an Apache instance do you need to have? OS specific needs? I found that using shared hosting providers like Webfaction has been great. I eventually found I needed greater needs for flexibility and bandwidth. In other words, what can you get for your budget? If you have USD50 to spend each month, it may be better to consider a virtual hosting solution like Linode....
Finally, I echo S.Lott's sentiments that no choice for a solution is perfect, and are subject to obsolescence.
Experience trumps hearsay. I've found that prototyping is a huge help. Make a prototype that uses the features you expect to be the most important for various frameworks. This helps route out any features that may not work "as advertised."
In general though, kudos for being willing to look at new technologies.
I have a set of criteria in different categories:
Activity & Documentation
Is there an active user base?
Is there an active development base?
Is the support responsive and information accessible?
Are there user and development guides and reference material?
These are essential, there needs to be traceability of all of these to build confidence in the solution.
Ease of use
Are basic features easy and complex features possible? I typically give a new framework a test drive and try to roll out a set of use cases to see how intuitive the framework is to use.
Is installation intuitive and simple for a local/dev installation and production deployment?
How is it backed up and upgraded?
What is the effort and UX for implementing a "Hello World" type blog post, static page, menu item, and plugin?
How are versions dealt with for the core & plugins?
Example (on the topic of Automated Testing/Continuous Integration solutions)
Several years ago I evaluated several Automated Testing solution. At the time Jenkins and TeamCity were front runners and in the end I chose TeamCity because of the UX, active user & development base and quality of accessible documentation.
Example (CMS for a blog)
This criteria is also why I prefer to use Wordpress over other options. While wordpress has its shortcomings, the user and development base is strong and active which leads to a software architecture with more potential to evolve over time and maintain its relevance and a development community that provides quality plugins and themes to choose from.