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 have seen several applications that explain features to the user when they first use it or bring new features to their attention after an upgrade. This kind of documentation appears directly within the app and in the midst of the user's flow, e.g. by laying a speech bubble over the UI which points to the button or any other element. Usually it appears once and never again.
Unfortunately I don't know how to call this approach, which makes it hard to even google about it. It seems to be a quite modern UX approach.
I am wondering what architectural or design patterns are used or whether there are any notable libraries to implement that. The issue I am trying to address is that this is a cross-cutting thing which creeps into any place and any time in the work flows - and yet you want to keep this whole concern out of the "actual" functionality.
For example, the user might request a page in an MVC webapp. The controller fetches data, executes actions and serves a view. On that view is a new tab. The user has not ever seen this and you want to display a friendly message "click here to...". This means that in some place, probably in the controller, you must detect that this feature has not been explained to the user yet - you load a message from a bundle and send it to the view. The view renders a speech bubble in addition to the tab. This logic has nothing to do with the actual functionality. Ideally you can keep it out of the controller as well as the view.
I was thinking whether an Aspect-Oriented-Programming approach could help.
Is there any blog, library, established patterns?
Please note: I am not asking how to render a speech bubble. My concern is that I don't want the logic - to decide when to display it ("has the user ever seen the message? Have they picked "don't show again?"), what to display, and where to display it - to be spread across the whole application source code. Ideally it could be packed into its own package or project.
Similar considerations can apply for collecting feature usage statistics or for adding a user feedback channel in various places.
Update: I finally got an answer point to exactly what I was looking for. Since finding a term for it was the main issue, I am adding some of the keywords found in Shahrokh's answer so as to help future readers find this Q&A: This thing can be called an introduction, step-by-step guide, page guide, or a guided website tour for first-time users; the answer features intro.js, aSimpleTourPlugin, pageguide.js, joyride, Codrops, Bootstro.js, jQuery SiteTour, jQuery Tourbus, Trip.js, and Crumble.
List of Web Page User Guide or Website Tour for your web page is here.
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 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 4 years ago.
Improve this question
In my particular situation, I have a comment form than cannot be used until the user has logged in and joined a specific topic. Then, they can comment on that topic.
In your opinion, should I hide the comment form completely, or disable it and prompt the user to complete the necessary requirements.
Disabling them saves the user from effortlessly looking for functionality she knew to exist before. So in general, hiding something completely from view just generates frustration. Remember the dynamically populated menus in Office 2000 to 2003? Then you know what I mean (cf. Jensen Harris' blog posts on that topic).
I suggest you should disable them and make it clear in what states they are available and how to achieve that.
In some cases, however, such as the application we are developing right now, functionality being there or not depends more on the user's permissions than on the current state of the program. In such cases it can be helpful to just hide things that shouldn't be accessible since users never get to the point where they could use the controls. Simply because they're lacking privileges. See for example Stack Overflow's moderation tools which are accessible once you get above 10k rep but are never shown before, not even as disabled.
If you don't want the user to know there is a comment form you should hide it.
If you want the user to know there's a comment form, but it is not (yet) available to them, you should disable it (gray it out).
There are good reasons why you might want to hide instead of gray. If you are security-trimming the interface, for example.
Gray out.
You want users to be aware of what options are available. If they're hidden a user may never know that additional setting exists.
EDIT:
I guess what I'm trying to say is if you really should hide an option you'll know. IE spacing issues, security, whatnot.
No matter what you do to visually imply something is disabled, old/inexperienced/hasty users will lose time trying to comprehend that the form looks like a form but it isn't.
I would go with a clear message instead.
gray them out. if they click on them provide a message stating why they are unavailable.
Hide the form and provide a message such as:
"Comment on this article by signing in or registering" which links to the login and registration form, once they have registered they should be directed back to the comment form so they can leave a comment.
Leaving the form visible but inactive would make the user think they have to click somewhere special to activate it.
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 off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
This is often a bit of a problem for lone developers working on a product or a service. How can they get the word out about their product?
I recently finished a project of mine and I'm struggling a bit to spread word of it.
What do you think is the best way to promote your new product/service?
Although this question isn't strictly programming related, it's a good question for programmers wanting to get their creation out and about.
You should have a short tutorial explaining what your product does and how to use it without having to install anything or fill out a single form. I'm not exactly sure what AnyHub (The OP's website) does with my files, how I would share or manage them or why you are doing it for free.
Look at Web 2.0 sensations and see how they streamline the process from hit to customer. For example Twitter has the What, Why and How buttons right there on the front page and nothing else to distract you from them. It also has motivating testimonials there too, and is themed to represent the idea.
Also, you should be trying to find a point of pain that many people have and try to ease that. Twitter knows it is getting impossible to tell your friends what you are doing via email, sms, blogs, feeds, rss and so on so takes care of it. What do you provide (other than an alternative pricing model?) Tell me on your website.
The internet (obviously).
If you're going at it alone, grassroots via Blogging, Facebook, and Twitter work.
You can also purchase google ad words, and other ad-related venues.
You can consider an open source version of your project, or joining tradegroups/ forums related to whatver problem your product addresses, and start to build a following (but please DONT spam these groups).
Mobile phone applications are really easy to promote nowdays, thanks to Apple's iPhone App Store paradigm. Now all major players (RIM, Nokia, Palm, etc) are opening their own application stores which takes away much of the promotion effort from the developer. As long as your application, game, etc is interesting it will sell by itself. Nevertheless, everything depends on the first week you launch your app and it is up on the list of the newest arrivals.
In the desktop world things are more difficult although Sun recently announced a similar promotion scheme for Java applications. More might follow, but it will depend on Sun's success or failure.
I believe (and actually hope) that centralized "selling services" will be the primary way of buying applications, games, plug-ins, services, etc in the near future. It is far too convenient to pass.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
My boss tasked me with finding a sort of system for a customer to be able to log into a website and view their website as a work in progress (so employees would obviously have to be able to upload their work). All communication would be handled through this website.
It sounds like a forum, but customers would not be able to see each others' projects. It's private and the only people who could see all customer projects are employees.
I'm sure I could implement it using a forum and some visibility options, but I was just wondering if anyone knew of any systems similar to this.
Something like Basecamp would work - set up a Basecamp project for each customer/project and only give customers access to the appropriate projects, while your employees could have access to all.
Sharepoint is always on option if you are on the Windows platform. Also might want to look into Mingle. I haven't used it in a couple version, but it showed real promise.
Most of the people I see that sub out a website don't get to view the actual website themselves live on the Internet - because just simply its to easy to copy down the underlying HTML (unless of course much of it is server side scripts, but that's another store). Most of the time they just get screen shots (and perhaps user testing on the developers machine) until most of the money has changed hands.
Why not put up a bulletin board (like phpBB, but not necessarily phpBB) and segregate what each client can see. Then you can post screen shots in each customer's area and let them comment and discuss?
We have a Forum-style section at the bottom of the page (on our DEV sites) where people can add a Comment. The ideas is that a Tester, finding an issue, will check the Comments at the bottom of the page before adding a new (possibly duplicate) Comment.
We allow Assignment of the issues, internally, and then Assigning it back to the Author for Approval, once it is fixed.
Additionally testers mark the page as "Operational" or "Broken". We have a report of pages not-yet--reviewed - so testers can make sure they have achieved 100% coverage.
We have routines that will reset all pages to "Test required" (ready for another round of testing), optionally leaving pages marked as "Broken" at that status, or resetting everything to "Testing required".
We tend to use sub domains for this - so TEST.MyDomain.COM - and have the ROBOTS.TXT set to disallow all search engine spidering - so only those in the-know will find the site. (I suppose you could be more paranoid, and require password-access, but our clients are about to launch the site and not paranoid about outsiders seeing it - indeed, they often ask Customers etc. to have-a-look)
Having said that we do have a "Known user login" which proffers no specific admin powers, but does log any Comments to that specific user - always useful if we can't work out what the heck their Comment actually meant!