Are there any tools for privately showing a customer progress on their work, and having discussions with the developers? [closed] - project-management

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!

Related

Building documentation into software [closed]

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.

Should I allow my clients to open tickets/access trac? [closed]

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
I just installed trac for this project I'm working on, since it's turned out to be a bit bigger than I anticipated. I've added a bunch of tickets with my clients requests which come in the form of emails, phone calls, and meetings. I've also added some stuff I know needs to be done/fixed but they haven't specifically requested. Should I grant them access to trac so they can submit the tickets themselves so I don't have to keep translating (words into tickets) for them? They're very non-technical, so I'm not sure how well it would work; they might open tickets and not provide enough detail, or get confused by all the different fields.
If your answer is "no", should I at least let them view the tickets, so they can see what I'm working on, what's been done, hasn't been done?
My experience (rather small, though) shows that allowing non-technical people to create tickets directly just won't work. You'll finish up editing those tickets yourself and constantly asking for details anyway. If I were you, I'd choose email for feedback and problem reporting.
However, it is a good idea to share existing tickets, read-only. Some people -- even non-technical ones -- are able to learn out of this how to create right tickets. Others would be happy to follow their particular problem while it's being solved.
So much of software development is managing clients and their expectations. Giving them write access to your bug database may suggest to them that they are now directing and in control of the project more than they actually are. Add to that the inevitable questions that will follow ("How do I do X/Y/Z?") and it's a massive headache waiting to happen.
I would consider read-only access but only if the client was technical enough and experienced enough with software development to understand how these tools are used. Otherwise I would stick with much lower-tech but much simpler todos-in-a-text-file, which I find myself using more often than not.
#Brendan Long trust me, it can get much worse when you give people a false perception about how much fine-grained control they have on a project.
At my company, we're struggling to get good problem descriptions in tickets from a technical audience (system administrators, technical consultants etc), and more often than not it takes inquiries from our professional helpdesk before an issue is layed out clear enough for a developer to work on.
Thus, from many years of experience, I would clearly advise against letting all your customers open tickets (unless you can narrow them down to a technical audience) because it will not save you any work compared to e-mails.
Read access is a good idea (because people will still feel much more involved) - you just have to make sure that you do not have too many tickets (usually low prio bugs or requests) that remain in the same state for a long time because this will start to frustrate the person who submitted it (better to close such a ticket in a timely manner if you can't or do not want to work on it, this kind of honesty if usually more appreciated than letting a ticket open for years ,-).
I used to communicate with a client via email and phone, and at some point I realized it was just too hard to keep track of things. I set up an account on Unfuddle (similar to Fogbugz but free), with just accounts for the two of us and it was immensely helpful.
When we first started, I did a lot of editing on new tickets, but it was still much better than keeping track of emails, and she figured out how to create tickets in the form I needed pretty quickly (I assume because now she can see how I keep track of what she's saying).
Anyway, if you're just using email now, it's not like it can get worse ;)

Is it unethical to send data to myself once a customer installs my software? [closed]

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
I'm trying to get an idea of how often my software is being installed. I was thinking about just including a simple URL call in the background the very first time the software is started. I am not trying to gather a lot of information. I really just want to get the date and time the software was installed. Is this unethical or commonly done by other developers?
You could always just have the installer open up a "Thank you for installing our product" page that's hosted on your web server. Since this page would normally only be hit after an install it should give you a decent indicator without being evil.
P.s. Before anyone hounds me on this please note that Firefox does this directly after an install.
In my opinion, yes, sending any data back that isn't authorized is unethical. Most software will prompt you to ask if it's OK to send back anonymous usage data. You could also track downloads and guestimate how many of them are actually installed.
There are a number of software products that gather data from the user but they all get the user's consent before sending any information. I suggest you do the following:
Ask the users to register, this way you will know some basic information like (roughly) when the software was installed.
If you need more complex/interesting usage statistics then make this a feature that users can easily turn off. Some people are not comfortable sending any data to you, Eclipse does this very well, the first time it wants to gather some usage statistics it allows the user to turn off the feature right away.
Finally , which ever way you implement this feature ensure that the users can see exactly what data you are collecting and sending and can choose to not do so.
If you do this in this correctly way you will gather some data in a way that does annoy your users or intrude on their privacy.
Just popup before installation:
"If you click Yes, the date and time the software was installed will be sent to us via your Internet connection. We would appreciate it a lot."
Let "Yes" be the default option and avoid the popup if there is no Internet connection available.
Doing it behind the scenes is unethical in my opinion.
you will always have to ask before calling home with anything, no matter how harmless you think it is.
kind of like you should always ask permission before putting a shortcut on a desktop.
If you want to do that — ask user permission.
Some companies just have automatic check for updates feature.
Only do this if your application uses the network as a primary function, otherwise a user will get weirded out by their standalone application asking to get internet access through their firewall.
Also: If you add in-line updates to your software, or ask to check for software updates periodically, you can easily log this information.
this is kind of tricky, if u are getting the information about the software only; without identifying the user, perhaps it might be passed as alright.
just think of google, i know it never gets installed on your system, but chrome again is a google product, which i believe probes ur google searches to give relevant advertisements. what is reading a cookie, is it any different from reading information from your computer.
also i have seen relevant advertising poping up in yahoo mail when i search for shopping stuff on google. they for sure are reading some info on your computer or browser session.
I think its ok to send the info from software, as long as u have no way to identify from what user it is coming from.
I don't see any particular areas of unethical or illegality except for this: My software, my computer, none of your business if I want to install it or just have it sitting in an installer.
Although I think a convincing argument could be made that it literally is your business to know about your software's installs.
Best route is simply to request to send 'anonymous usage information'.
How many of you windows users tell windows its OK to phone home and verify that your copy is genuine?
0.
There are a lot of high and mighty my-computer-is-my-domain answers here, and the bottom line is while its rude, its not against the law. Rather, its commonplace. Stick a disclosure in the EULA and you're good to go.
It is unethical to hide your collection of usage statistics.
That said, almost every website has a TON of personally identifiable information in the form of web logs that are almost never used to their "fullest potential for evil"
To ethically collect your install count just ask the users to activate the product on first usage or ....
Provide something useful! Prompt the user to check for updates on first use.
This approach IS ethical, can get you better and more relevant data (you can put voluntary forms together) and allows you to make a value exchange.
I think the circumstances also play a part.
If the app is a free app and the developers find that knowing each time an app is installed then as long as the user is told then most users wouldn't have an issue with that.
If the app contains sensitivie data (i.e. financial or credentials) and you notice the app calling home then that would freak most users out and wonder what else is being sent.
Also another point is having it call home each time the app is installed doesn't really tell the developers much, what if a user reinstalls the app or the operating system? What if the call home is denied by security software or their computer isn't even connected?
In my opinion if you can't collect meaningful useful stats then is it really worth collecting them to analyze them?
It’s unethical.
In the case the URL is opened in the default browser: A user might have explictly set beforehand that your tool should not be allowed to connect to the Internet. If your tool just calls the browser, you are circumventing this.
In some countries, users may face oppression or punishment for using specific tools. While they might manage to get the tool via sneakernet, your phoning home would be detectable by authorities.
You might lose/change your domain. If Malice registers it, she’ll have access to the incoming data from installations of your tool.
When your software wants to phone home, inform your users beforehand and allow them to cancel it.

How to promote a new product/service? [closed]

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.

Where can I find a template for documentation about server-side installation of software? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm looking for a good template on server-side installation of software for a project I'm working on.
The client-side is pretty straight-forward. The server-side installation is a little trickier. It is made up of several pieces (services, database connections, dependencies, ports that need to be unblocked, etc.). During a recent test, several undocumented pieces were discovered. Now I need to create installation documentation for our disaster-recovery plans and ways to test the installation without necessarily having a "full-up" system to test on.
I'd really like a suggestion of where I can get a template or a really good example of such a document. I'd like it to be something that an operator could read and comprehend in the heat of a recovery.
[EDIT]
Our current documentation comes mainly from the questions our administrators have had during off-site tests. As new code is written, I'd like to make sure the documentation is written ahead of time. I've been collecting VMWare images to start testing, but was looking for some good examples. It's a Windows Server shop (2000 & 2003). Word templates would be great, but if I could see good documentation, I could create the templates. Any suggestions about what should be tested would be great as well.
[2nd EDIT]
I've gotten several good ideas from the answers posted. After changing my Google search, I came up with some good starting points. They're not perfect, but they are a good start.
Microsoft Exchange - http://technet.microsoft.com/en-us/library/bb125074(EXCHG.65).aspx
iPhone - http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
http://www.novell.com/documentation/gwgateways/gw7_exch/index.html?page=/documentation/gwgateways/gw7_exch/data/ab32nt1.html
http://cregan.wordpress.com/2006/06/22/exchange-2003-step-by-step-installation-instructions/
http://technet.microsoft.com/en-us/magazine/cc160942.aspx
Covers planning in the design stage well - http://www.onlamp.com/pub/a/onlamp/2004/04/08/disaster_recovery.html?page=2
[Edit 10/29/2008]
THIS is the type sample I was looking for. It doesn't have a lot of garbage, but seems to explain enough of the why along with the how http://wiki.alfresco.com/wiki/Installing_Labs_3_Nile
The most complete method that we've come up with for creating our DR documentation, involves going through a full cycle (or two) of installation, and documenting each step along the way.
I realize this can be a bit difficult if you don't have a test (or replacement) system to use to create your documentation - but it's worth lobbying for running through this cycle at least once.
(I recommend twice, the second being done by someone not involved with the project - this is how you test the documentation for future admins, who may not be as experienced with the process.)
A side effect of the above is that your documentation grows fairly large - last I had to do it, I believe the completed installation manual for our database servers was 30+ pages.
What should be tested? Well, in the case of a web site, "can you get to the page?" Include a URL as a starting point and let the admin click through to a certain point. It is not necessary for the admin to go through the whole QA cycle, just a confirmation that what you meant to be deployed is really what got deployed.
Other ideas
Also, we (my team at my last job) had QA test the deployment. As a QA person should be, he was not intimate with the details and as he deployed to QA, we were able to get feedback on what went wrong.
Another thing that is useful is sitting down with the admin(s) before the deployment. Go over the instructions and make sure they understand them the same way you do.
Template? Just make sections that have fields for data such as URL to DEV, QA, and PROD. When you write out the instruction you can refer to those. Just make it clear what is being deployed.
Depending on the admins, automation is helpful. I've had windows admins that want a Word doc with step by step instructions and other admins that wanted a script.
However, some helpful things to include, probably as sections
Database changes
Scripts to run
Verification that they worked
Configuration changes
what are the change
where is a version of the new file (In my case they diffed the two, which helped reduced errors concerning production-specific values)
General verification
what should be different from the user perspective (feature changes)
For web farm deployments, it might be helpful to have a coordination document concerning how the servers need to be pulled in and out of pool.

Resources