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 9 years ago.
Improve this question
Here's an interesting writeup of using eye tracking software to generate "heat maps" that show where on the screen users spend the majority of their time.
Any leads as to good packages for doing this, without paying through the nose for somebody to come in and run the assessment for you?
http://www.useit.com/eyetracking
I used to do a fair bit of qualitative eye tracking research a few years ago. (I was the guy you'd be "paying through the nose")
Mouse-tracking and eye tracking are very different. However, both can be used with the same goal in mind - to reveal telling aspects of user behaviour which can then be applied in improving the UI design of your system.
To say mouse-tracking is an alternative to eye-tracking is like saying a trowel is an alternative to a garden fork. Both tools are used in gardening, but both have their own strengths and weaknesses, and as a result they get used for different jobs.
Eye-tracking is viewed by most researchers as a niche tool - something that has its place, but not the tool you'd reach for by default every time. The only big exception is for consultancy firms that specialise in eye tracking - if all you have is hammers, everything you see is a nail. Particularly when each hammer costs $36,000.
Eye tracking is often criticised as an expensive way to evaluate your system. It also criticised as being easy to use poorly. It's "wow" factor often means that people are so busy being blown away, they don't real stopping to critically evaluate the real benefits of eye tracking over other approaches (like good old usability testing).
A useful blog posting on the topic of Eye Tracking might also be of interest.
You may want to look at this page. It was recommended in another question.
Here are some good reads on this topic:
http://www.webusability.co.uk/2009/eye-tracking-greater-insight-or-fashion-fad
http://www.useit.com/alertbox/reading_pattern.html
http://eyetracking.oneupweb.com/
http://www.eyetracking.com.ua/eng/visualization/9.html
try these options - they are usability research/testing options for "cheapskates" (discount methods):
http://userfly.com
http://www.robotreplay.com
http://clickegg.com - i've used this & was very good.
http://www.clickdensity.com - i've used this & was very good.
NB: They are alternatives to eye tracking. They are mouse tracking. Eye tracking is expensive.
You could do a talk aloud session with a sample of users - each user telling you what they are looking at as they go. Alternatively, use mouse tracking & ask your users to move the mouse over the areas they are looking at. Its an idea.
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 7 years ago.
Improve this question
I am building a 'software as a service' website that will be charging users a small monthly fee. I am considering changing the Github repository over from Private to Public. Essentially open sourcing it. Is this suicide? I would like the community to be able to benefit from the code. It is unlikely that I will accept any push request so I'm not going to gain anything in that regard. It is community based, so I think most of the value would be lost by someone self hosting it. It is for a very niche audience so I doubt someone else will start a competing hosting. I would really like the code to be in the open, but not at the expense of my idea of course. How does everyone else feel about this? What is common practice?
Conclusion, I'm keeping it closed for the time being. I may look to open source sometime after launch however.
Since you are not going to accept pushes you might as well hold on get your code stable and then publish it for others to learn and benefit from. You are still building the service, so its not going to attract too many eyeballs either.
From a business point of you, you might want to have a reasonable community around your service before you opensource it. if you are still budding who knows if its taken up by a stronger competitor. If your idea is patented its a different story.
To be honest, and this is not likely going to be a popular answer, but to myself, I would keep it closed for a period of time.
The reasons for this are simple, establish your foothold in the marketplace, build your userbase, your brand, then it gives you a mechanism to market your product further by selectively or completely open sourcing components of your system.
I say do it for both personal benefit and potential strategic benefit ... afterall, alot of software IS a service
Most open-source projects stand to provide a return in the right circumstances. Don't forget, unless you have a patent or some massive advance that is so complex and unfathomable that nobody can re-implement it .. if they want to they will anyway, so you have little protection staying closed source anyway ... even more interesting is that the open-source equivalent may well overtake your proprietary one if it garners support.
People may send you great ideas you never thought of, or take your codebase in a direction you would not have predicted. Unless you have significant value in terms of IP or strategic position tied up in the source code ... releasing it will probably do more good than harm.
Also, by being first to the open-source arena with your code, you gain control over any resulting community driven development ... if somone reimplemented your functionality and went open source ... could you compete on any front?
I know it is a cliche, but probably for good reason, but read The Cathedral and the Bazaar and the essay Open Source as a Signalling Device - An Economic Analysis which is an interesting read. Michael E. Porter's texts on competition analysis are interesting when held up against the mixed value economics and competitive forces of open source and shows how disruptive open-sourcing a product can be to competitors ... and how it can add value to your market position. Also, whilst counterintuative, it can raise the barriers to a successful entry by competitors.
More food for thought on the advantages and disadvantages of open sourcing:
What the DoD thinks of open source
Alfred H. Essa "Innovation and strategic advantage: lessons from open source" (warning, journal link)
I like to fix flaws wherever I see them, and perhaps I am one of your users. I'd rather send a patch than send a potentially nagging-sounding email any day.
What benefit are you hoping to gain from making the code open source? If you don't want the input of other developers then there are very few advantages and a whole lot of potential disadvantages.
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 7 years ago.
Improve this question
I have already built a site from scratch. It has banning, PM, comments, etc. The PMs and comments are done using markdown (like SO).
There are pros and cons for writing my own or using another software. But some cons keeping me from using another forum software is
Multiple Logins: One for the site, one for separate forums.
Need to Customization code: I'll need to change the toolbar in the forum software so I can access pages on the regular site.
Look consistency: It may look drastically different from my site even after applying lots of css changes.
Banning and User consistency. Users may be ban on site or on forums but not the other. users may select a different or multiple usernames on the forum instead of being forced to use the same username on both site and forum.
Should I write my own forum code or should I use something already written? What are some reasons for or against writing my own and using forum software?
The heuristic I tend to use is that if at least two or three of these are true, it's probably worth writing yourself:
It's one of your core business offerings.
You have the time, money and resource to specify, design, build, test and support it.
The amount of time you would need to spend evaluating, prototyping with, integrating and customising off-the-shelf packages is near to or greater than the amount of time you estimate that it would take you to build your own.
The off-the-shelf packages do not have good support. By 'good support' I mean that you can raise an issue, and be assured that somebody will look into your specific issue and provide a fix if it is found to be a bug.
None of the off-the-shelf packages meet your quality bar for security, performance, quality, etc.
You are not writing open-source software, and the off-the-shelf packages have a viral open-source license; be particularly wary of AGPL and other similar licenses.
One of the oft-quoted articles about this is from Joel Spolsky. Lately he seems to have just been writing flame-bait, but this was one of his worthwhile early posts.
Note that you can also take a combination approach, and use some pre-built things such as recaptcha and gravatar even from within a bespoke solution.
Writing your own forum software is nowadays in almost no case useful. The available software is highly customizable. For example, you can create your own skin to fit with the layout of your website. You can integrate the login with that of your website.
Writing your own forum is so complicated that the quality of your own software will be much lower than of something like phpBB or vBulletin. And dont forget the security bugs, the mentioned software has been reviewed by a huge amount of people. Until you reach the same quality (functionality, stability, security, etc), your website will be outdated and your forum software with it.
Once again, the current forum software is so adaptable and extensible, that it doesnt make sense to make your own.
I think it highly depends on your needs for the forum.
First off, is the forum itself an essential part of your website's function? Or is it more of a 'support' style forum?
If it's essential to your daily business, then it makes more sense to write your own - or at least highly customize an existing package.
If what you need instead, however, is a vehicle for customer support, or some sort of generic community revolving around your site, I might recommend looking at a completely different vehicle: something like http://getsatisfaction.com, or a Google Group, or some such.
(I'm in no way affiliated with either of those sites).
Regardless of the solution you choose, I'd recommend you give some serious thought to how essential the forum is. If it's not, then I wouldn't waste too much time configuring/setting one up. Instead, focus on what your site's main draw is, and spend the bulk of your time on improving that. You and your userbase will be much happier with that, IMO.
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
Our investor wants a SDLC. I've never written one before, and I don't have enough time to go and buy a book, or spend much time learning about them. From what I've been told about them, they consist of requirements (what needs to be done), and a list is done. Is this correct?
Update:
I have found this article which really helps to explain things in simple terms and very quickly. Not that I think an SDLC should be done quickly. In my case, I have no other option.
There are lots of ideas about SDLC out there. You can't swing a cat without hitting one.
What have you done to develop software that attracted your investor in the first place? Can't you describe that? Why do you have to go out and "learn one"?
There's a number of choices:
Waterfall: requirements->design->build->test->deploy,
all in sequence
Iterative: similar to waterfall, but you break the design into smaller pieces, of 1-2 week duration, that are delivered at the end of the iteration.
Extreme Programming (XP): Kent Beck's approach; no BDUF (Big Design Up Front). Everything is designed, built, and delivered in small pieces.
Scrum: Agile, iterative, but not as dogmatic as XP.
Rational Unified Process: Waterfall from IBM.
Not really; that's more project management. That's what you need at the point where you've figured out how you're going to develop software.
For the 'how' of developing Software, the two 'biggies' are Agile and Waterfall; with a weird hybrid in between the two.
But that's only one part of the Software Development Life Cycle: You still have to have a maintenance and deployment plan.
My question for you: If someone's giving you money, and they want a plan, isn't it in your best interest to read a book about the SDLC and give them a plan?
If your investor wants you to describe the SDLC, he wants that you describe how looks the life of a software project which is done by you from its plan, birth, through growth to maturity and death. That is the reason why it has "life" in its name. The result of SDLC should be "software" hence the first word. The "development" part comes from the fact that you are responsible for planning, specifying, designing and implementation of the software, you should create (develop) the software. And finally, "cycle" means that, when the investor looks at you SDLC and thinks it is good (it produces quality and business value), he can ask you to use the same process once again in another project.
A complete SDLC meaning you need to perform Requirement gathering and Analysis-> Design (Design document creation) -> Coding and Unit testing -> Testing (System and Integrated testing) -> Deployment and Support -> Maintenance
I found this Blogg really helpful.
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 5 years ago.
Improve this question
We're a medium sized engineering shop (10-20). We are great at prioritizing and structuring work on our user facing stories and making customers happy. But the cobbler's children have no shoes. If it isn't about customers, we have 0 process.
I'm looking for systems to ensure we correctly prioritize and accomplish the non user facing work to keep a dev shop running: QA environments (pretty heavy, in our case), continuous integration systems, the packaging, and so forth.
Now, resources are always limited. We don't want to give the cobblers children 10 pair of the fanciest shoes, and specialized bike shoes to boot. We want to do the right, necessary work, with the same scrummy discipline that is applied to the rest of our development.
Tell me what system works for you: how to you prioritize and organize non-user facing work ? I want systems that are simple and integrate smoothly with scrum.
(I'm aware of a red box at the top of this text, indicating that Stack Overflow's automated question parser thinks this is a subjective question that can't be answered - I think there are likely 2 or 3 excellent answers that can be or have been proven viable - and process is integral to programming. So here is some psuedocode representing our process. Fix this algorithym).
IBacklog GetBacklogForWork(IWork requestedWork)
{
if(requestedWork.IsUserFacing) return new PrioritizedBacklogRepository();
// Everything else. Priority largely based on spare time and who thinks its a neat idea
return new RandomizedPriorityRepository();
}
void HandleIncomingSuggestionsForWork(IEnumerable(IWork) ideas)
{
foreach(work in ideas) GetBacklogForWork(work).Insert(work);
}
Someone involved is using and depending on the results of the project. This is necessarily true; if it weren't true, why would you be doing it?
When you identify the person who most depends upon, or cares most about, the results of the project, you have the "user" that your project is facing. Make that person the customer.
IMO something like "QA environments" is, in a sense, user-facing work.
Quality is admittedly a "non-functional" requirement (so there isn't necessarily an associated "story"). But, you may have a non-functional requirement like "the software must be tested before it's shipped". You can assign a relative priority to such a requirement ("how important is it that software be tested?"), and then execute as usual (decide how to implement that requirement, estimate how long it will take to implement, schedule the implementation, assign the implementation, etc.).
What we do where I work is to have a percentage, right now around 15% give or take a few percent, that is spent on internal tasks that are non-user facing work. This way the technical debt is handled and if the task backlog becomes rather large then a sprint may be spent on it instead of new functionality. The way that last one would get pitched to the user or customer is that there will be a time where just maintenance and preventive work is done so there aren't any new functions coming after the next sprint.
That's one idea that can be tweaked a bit though it isn't necessarily fully flushed out yet.
The way I've seen it work more or less ok is to try to do as much as possible of the non-functional/non-user-facing as PART of a related user-facing activity, or the first user-facing activity that requires it.
This is the easiest to cope with, as it just reflects the needs of the development organization in order to maintain sustainable velocity moving forward.
Additional work which cannot be related will be done using a percentage as described by JB King.
The alternative of pitching it as an investment with such and such ROI to the PO is a theoretically sexy concept, but with real life POs I've seen it rarely works.
Its very hard to get POs to understand the investment, not to mention actually being strong enough to delay functionality for it.
Its sometimes the difficult role of the development teams to be the guys that "slow things down" in order to keep a sustainable situation.
Dev managers sometimes feel really bad about this whole sitation, regardless of the chosen approach. My recommendation both as someone who's been in that spot, as well as an Agile coach, is that as long as you feel you are doing the right thing for the business, focusing on non-functional work that is required NOW and has a relatively quick ROI, you should feel ok about this.
Cautionary note: This is an area where self-organization is really put to the challenge. Organization needs to trust the team to do the right thing, and the team needs to earn and not abuse that trust. Its a sign of maturity for an individual or a team to know the right balance.
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 7 years ago.
Improve this question
I am working in a small team on some projects in my spare time. We are having the problem that we seem to go in circles and are not able to get our products developed - however this is not a problem during my day job. The lack of face-to-face communication seems to have a real impact on productivity.
Any examples of software or methodologies in use by the open source development community would be appreciated.
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and
responsibilities.
Let each developer
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good luck.