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.
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 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.
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 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 5 years ago.
Improve this question
I am going to be starting a new job in a few weeks where I will be responsible for both the maintenance and development of a couple of existing web applications and the development of new web applications.
As I will be the only developer on the project and the previous developer was more of a hobbyist, no formal project management or planning techniques have been followed. Additionally no bug tracking has been used or if anything has been recorded its just been notes on paper.
I would therefore like to introduce a better system to help resolve some of the issues and help ensure things run more smoothly. I intend to develop using an agile process (likely scrum) and would therefore like to know what all-in-one solutions people could recommend for me to look into further. I am looking for something which will provide at minimum:
Project Planning
Defining new features
Time estimating
Ability to organise tasks by priority
Project Management
Tracking active tasks
Reporting
Bug Tracking
I would also like to let other staff easily submit new bugs in the applications which they find or customers report. Additionally support for them to add new stories / high level tasks would be of use so they can note down other new requirments/features and I can then work with them to outline more detailed tasks and estimates.
So far I have looked at a number of systems including:
FogBugz - Seems great for bug reporting but would need something else for project planning / management
Agile Buddy - This is probably the best solution I have found so far
Trac
Smart Sheets
Pivotal Tracker
However, as I have not actually used any of these systems myself I do not know what ones would be best or whether there is a better solution out there??? So any recommendations you can provide would be much appreciated.
Actually, FogBugz does project management as well. It will even try to learn how accurate time estimates for features are from each user, and give you estimated milestone completion times accordingly, with probabilities of finishing at various dates. I've used it for the bug tracking, and really liked it, but I've also read enough about its project management features to know that it has them, and they're pretty good.
FogBugz feature list
When I was working as a solitary developer, I picked up a copy of Planning Extreme Programming and bought a pack of 3x5 cards and a plastic box for them. I used those in the Planning Game and stuck the ones I was working on on my wall. My boss could walk by and see what I was working on. This worked well and cost little.
We're currently using Zen at work - it's a web-based Kanban board for planning. This is nice when your stakeholders aren't co-located or if priorities/requirements change frequently.
You can enter bugs as user stories with either system, or you could use a separate defect-tracking system.
I'd question if Scrum is suitable for a one-developer shop. It's targeted towards project management. I'd rather not have a stand-up meeting with myself. ;) XP (minus pair programming) works fine for a solitary developer.
For a one-man show, you don't need any tools to speak of.
Tools -- generally -- are for coordination.
If it's just you, what -- precisely -- are you coordinating?
If you want to make things visible, a pair of simple internally-focused web pages built from static content will do.
Bugs.
Burndown for Features.
That's about it. Use the simplest tools you can possibly use. I recommend using docutils to generate the HTML from plain, simple text.
Don't go tool-happy until you have a large enough team that simple text doesn't work any more.
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 7 years ago.
Improve this question
When prototyping initial GUI functionality with a customer is it better to use a pen/paper drawing or to mock something up using a tool and show them that ?
The argument against a tool generated design being that the customer can sometimes focus on the low-level specifics of the mock-up rather than taking a higher level functional view of the GUI overall.
Always start with paper or paper-like mock-ups first. You do not want to fall into a trap of giving the impression of completeness when the back-end is completely hollow.
A polished prototype or pixel-perfect example puts too much emphasis on the design. With an obvious sketch, you have a better shot of discussing desired functionality and content rather than colors, photos, and other stylistic matters. There will be time for that discussion later in the project.
Jeff discusses paper prototyping in his Coding Horror article UI-First Software Development
Click the "Watch a video!" link at twitter.com to see an interesting take on the idea from Common Craft.
The "Napkin Look & Feel" for Java is really cool for prototyping. An actual, functioning, clickable app that looks like it was drawn on a napkin. Check out this screenshot:
Seriously, how cool is that?
I would suggest you sit down with your client and use a tool like Mockupscreens and develop the UI interactively. A benefit it has over Napkin LAF is that it does not require coding, or indeed development tools of any kind
Check out Balsamiq
It does the "THIS IS NOT A FUNCTIONAL APP" napkin view very well and is easy to use.
Has a full featured demo you can try out online and as an added bonus you can email your XML to your client and they can tweak it and play with it and email it back to you without having to have a license.
There is a book called Paper Prototyping which details pen and paper drawing and what you can gain from it. I think it has a lot of benefits, particularly that you can, very early on (and easily), modify what the end result will be without much effort, and then start off on the right foot.
A basic paper version is the way to go for an initial mock-up. It's been my experience that if you do a "real" mock-up, even if you explain to the customer that it's a non-functional mock-up, they are confused when things don't work.
Bottom line: keep it as simple as possible. If it's on paper, there is no way the customer will confuse it with a working product.
For the first draft, I prefer to use graph paper (the stuff with a grid printed on it) and a pencil. The graph paper is great for helping to maintain proportions. Once the client and I have come to a conclusion I'll usually fill in the drawing with pen since pencil is prone to fading.
When I actually get around to building the digital prototype, I'll scan in the hand-drawn one and use it as a background template. Seems to work pretty well for me.
I think it is best to start with Paper/Whiteboards/White walls.
Once you have the basic structure, you can move it to Visio with the wireframe stencils
(Download a Stencil Kit)
(Visio Stencils for Information Architects).
Or you could use Denim (An Informal Tool For Early Stage Web Site and UI Design) with a tablet PC or Wacom tablets to design the GUI and run it as HTML website.
WireframeSketcher is a tool that helps quickly create wireframes, mockups and prototypes for desktop, web and mobile applications. It comes both as a standalone version and as a plug-in for Eclipse IDEs. It has some distinctive features like storyboards, components, linking and vector PDF export. Among supported IDEs are are Aptana, Flash Builder, Zend Studio and Rational Application Developer.
(source: wireframesketcher.com)
I've recenly used a windows App to prototype an application to a customer (the final interface has to be integrated into a website).
At first people thought that it would be the last version and they started to make very heavy criticism from the way controls were displayed to the words I had used (terminology and stuff) and the meeting time ended before we could even discuss the functionality itself.
That discussion dragged on for days and days until I told them that, being a mock (and not a final application) all input is welcome but we had to focus on the functionalities first and then we could move on to look and feel as well as terminology issues.
From thay meeting on I am always terrified of prototypes and mock-ups... Perhaps I should just have given them something made in visio instead.
You can try out ForeUI, it allow prototyping with different styles, what's more, it can make interactive prototype and run it in browser.
For a non-installation browser based tool you can try draft-it
It's free - and if you have a gmail account - no registration is needed.
Makes interactive/Step by Step Or Slide Show- prototypes. You can share your protoype with anyone you choose by just sending a link.
Works for us ...