I am developing an application which requires real time collaboration. I am planning to use a cshtml text area to allow the users to type. Is real time collaboration achievable using a text area?
Also, I have read a little about operational transformation. Can it be achieved using .net framework?
I am just a beginner and do not have much knowledge about algorithms that will help me achieve real time collaboration. Any help will be appreciated.
Thanking you in advance.
ShareJS is free, uses node.js to achieve what you are looking for, and implement a OT2 algorithm
For .Net there is no Operational Transformation out-of-the-box, however you can take a look to BeWeeBee SDK, (though is commercial software)
I am developing an application which requires real time collaboration. I am planning to use a cshtml text area to allow the users to type. Is real time collaboration achievable using a text area?
This really depends on the user experience you want to deliver. If you want to lock the textarea for one user whilst the other is editing then that might not be the nicest user experience but it's most definitely relatively easy to do.
If you want two or more users to be able to simultaneously edit the same text area then sending data_changed events between the users is reasonably easy using a realtime web technology but you'll need to handle the synchronisation of the textarea content between the users and handle collision detections. The user experience for this is also much more complex.
Also, I have read a little about operational transformation. Can it be achieved using .net framework?
I had to look up operational transformation and it partially answers the question about the user experience - it's non-blocking. Having skim-read the wiki doc I'd ask the question: why would it not be possible? You can communicate instantly between all users/application to notify them of changes (as stated: using a realtime-web technology) so you just need to implement and manage all the clever algorithmic stuff :) (I don't know if there's a component that will manage that for you)
For self hosted .NET realtime web technologies you might want to look at SignalR, XSockets, SuperWebSocket or WebSync.
If you want to get up and running a bit faster you might look at a hosted realtime web technology
This is an old question but there is some additional information that might be helpful. As previous answers mention, there are several options out there for text based data synchronization. Many of them based on Operational Transformation or CRDTs. These approaches are implemented in SDKs in many languages. (Full disclosure, I happen to be one of the authors of the Convergence).
However, you also need to take into account some of the other features required to implement collaborative editing. For example:
Presence: Who is there editing with you?
Collaboration Awareness: Things like shared cursors and selections?
Local vs. Group Undo: What happens when a user hits control-z? Are they undoing the last action they did, or the last action the other remote users did?
History: Knowing who did what is more complicated when multiple people are editing at the same time. When one user hits save (if there is a save) they may be saving actions performed by another user.
These are just a few examples of things to consider in collaborative editing beyond just data synchronization. When these questions come up, most answers focus solely on the data synchronization framework. At Convergence Labs, we help people work design collaborative editing applications and have implemented dozens of such apps. We have seen many times over that if all you put in is data synchronization, the user experience turns out to be pretty poor and users will not like the application.
So, in selecting a framework, look for something that helps you implement some of the other facets of real time editing, or at the least be prepared to implement them yourself on top of whatever tools you select.
Related
At my institution, we have a small library with 150 books and 50
users. We would like to use a simple online management system that
displays the books, lets users search and enter when they get and
return a book. (There is no librarian, the books are just in an
otherwise empty room.)
I'm not familiar with modern web content management systems. In the
old days, I would have just implemented a quick Perl/CGI script, but I
think there are better options nowadays?
What would be the simplest way to get/implement such a system? Django?
Ruby on Rails? Ideally, I'd like to just run it in my user account
without having to install database support etc.
Is it possible to do everything on one dynamic HTML page? What role
does AJAX play in such a system?
I suggest take a look at the available open source tools for libraries before deciding to build one from scratch:
http://www.libsuccess.org/index.php?title=Open_Source_Software#Great_Free.2FOpen_Source_Tools_for_Libraries
Another good resource in your research: http://www.oss4lib.org/
If you find an existing tool that fits the bill (or enough to make it worth extending), that will be important in guiding what platform/language/framework and techniques will be best to use.
If you want a quick and easy solution, you might want to consider using SQLite as the database backend, since it does not require any configuration or setup (except for the tables, of course).
If you have a machine standing around there, you could take a look at Qt/C++ or PyQt to create a simple user interface.
Pylons (there are lots of alternatives!) or any other web framework might do the job as well, but I guess it would be more work to create a web application than a quick and simple desktop application for this job.
This is quite a complicated question doesn't have a simple answer. The best I can do is point you in the direction of some resources to get you started:
Framework/CMS
Unfortunately, most frameworks require at least some minimal kind of db interaction. While this is not true for all, it would probably be easiest to steer clear of a framework, you probably don't need that much overhead anyway.
Javascript/AJAX
If you want things to happen without any seperate pageloads, then sure, you can use some ajax. However, you probably don't need anything this sophisiticated
How I Would Do It
If you really trusted your students enough to be diligent about checking in/out books, I think it would be easiest to just have a form on a webpage somewhere that they could enter the number of the book they are checking in/out. Then store the state of each book in a text file somewhere (you said you didn't want to use any db's), or even look into sqlite.
Again, you probably don't need all the overhead of a full framework/CMS. It would be fairly trivial to, as you said, write a quick script to handle the ISDN, ID, Title, Whatever of the book they are checking in/out.
Also, there are significantly easier languages to write scripts in these days than Perl and CGI. Try PHP, Ruby, or Java
I work in a small and young team of developers and we have problems that we are not sure how to solve.
On previous projects every developer have been working on tasks that were based on use cases. So, upon setting the system architecture, each team member worked on user interface and business logic of tasks assigned to him.
This kind of organization gave us the problems with UI. Each developer had his own logic about how UI should look like, where buttons should be, etc etc... and even if we've had one css designer a lot of refactoring had to be done in order to make web site to look compactly.
How do you deal with this issue?
Do you split tasks based on layer, not on whole use case?
Do you use some technical solution to achieve this or is it just written standard that every developer need to follow?
Thanks
Everyone has their own style and it would be difficult and a waste of time to define a standard that would get everyone to draw the UI in a consistent manner. Instead, elect your best UI designer to do what he does best and design the UI for the whole system. Funneling all UI changes through the designer would be difficult so just let your developers "mess it up" as they implement new use cases and just have your designer clean it up before the release. It shouldn't be hard for him/her to rearrange the existing forms and bring some consistency back to the UI.
I've found this 12 Standard Screen Patterns article very useful.
A solution might be to create sketches of all screens of your application, have them reviewed by an ergonomy-expert to correct the biggest mistakes, and, only then, give them to your developpers.
This way, they would know how the screens they are developping should look like -- there will still be a couple of differences in the end, but those should not be "big differences", and should be eaiser to fix.
And this would mean not each developper has to imagine what the perfect screen would look like : each one of those would be coherent with the others.
Adopt the tried and tested MVC system, let the view be decoupled from the business logic. Then ask a UI designer to produce sketches and work to that. UI's are something best done top-down from my experience. The user gets an overall view before being presented with all the details, defining and capturing this hierarchy makes good UI's. Coding of business logic is done as you mentioned on a use-case basis, mostly bottom-up and this is where the code falls out of sync with the UI.
Designate one person (preferably someone with graphic design experience, even if they're not really a programmer) and give them the authority to make cosmetic changes to all forms, pages and controls at any time, and have them be responsible for the overall look and feel of the application.
As far as metrics go, keep track of how much time this one person has to spend "fixing" each programmer's work, and make sure the programmers are aware of these numbers. The idea is to encourage them to make their stuff look like it should from the beginning, but also not to do weird things based on what they think stuff should look like. I've had to spend more time undoing my coworkers' bizarre design choices than anything else.
Don't be afraid to have outside sources review the design work of each programmer. It's very common for programmers to 1) produce horrible-looking UIs, and 2) believe the UIs look fantastic. You should do what the Army does with boot camp: break them down completely right from the start, so that you can build them back up again the right way.
Part of the problem with creating your own written standard is that while well meaning, there could be mistakes or better ways to do things than what's been standardized. For example, where I work, the standardized cancel button does nothing when you click on it (it's been wired to Reset).
Instead, I recommend choosing existing standards, such as The Macintosh Human Interface Guidelines or Windows User Experience Interaction Guidelines. Even if the standard is wrong, it's rarely profitable to deviate from widely established conventions.
Then pick up some good books for the developers, such as "Designing Interfaces: Patterns for Effective Interaction Design". Good user interface design is partially a matter of good taste, and while not every developer will be interested in the subject, it's in your best interest to help them improve.
Next, empower your QA team to file bugs when the interface for one product is inconsistent with another. The developer can then either standardize or justify the deviation if he has a reason. We do this; it works pretty well.
Lastly, go over your existing products and get a consensus on how their interfaces should be unified. Bring in (and keep) a usability expert if you can. I've seen good ones do amazing work.
There really is no clear solution for how to deal with UI problems. There are however several approaches one can take to combat the problem of having things become too complicated:
Use cases are usually cross disciplinary in nature, thus the responsibility to get a use case done should be split between the people who can implement it properly. Programmer and designer type of people need to cooperate.
Everyone in the team needs to keep in mind seperation of concerns, i.e. things that can be seperated must be kept that way preferably as early as possible. There are so many ways to do this: e.g. apply MVC pattern in your project (which is a very wide way to put it). Presentation and logic should be seperate so that changes in one layer should not affect the other.
Someone needs to be responsible for the overall UI design so it is consistent throughout the application. Preferably someone who is both a graphic designer and has some insight in usability. UI design is something that needs to be planned along with the use cases and revised constantly as development goes on. Consistent UI is very important and developers need to be on board on 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 6 years ago.
Improve this question
In some software company, who should be responsible for the UI design:
User
Designer
Manager
Boss
Depends on company size
etc.
In UI design I mean not only colors and images, but also control's layout, count, size, style, may be text user see.
In a small company, the answer is "whoever is good at it". Some of our best graphics were designed by a technical author who happened to have a flair for graphic design. Don't assume that someone has to have the right job title to do a creative job - innate talent trumps a job title any day!
Most companies have GUI experts and who design the front end. Some even have altogether different person(s) in team for interface layer programming, leading to tools like Expression which are supposed to draw a line between both jobs.
It however depends completely on company/person developing the application.
Well, UI design should be a collaborative effort. You as a developer should provide technical suggestions as you know the system from the inside. Your boss does provide the final answer, but he/she can provide a different opinion that you may not have realized.
Usually though, the business partner decides the final UI. They have have the practical experience with whatever your program is going to solve. They sometimes know for a fact what the user wants and expects from a solution. The UI would be a lot friendlier if the developer and business partner collaborated on the design.
A dedicated UI person is valuable to a development team, but several roles should have involvement in UI development. Ideally a UI person should be able to bridge between designers and programmers, so that the final design can be implemented with minimal technical problems. UI should be reviewed with programmers to make sure it can be translated to the web (or whatever platform you're working on) and with business analysts to make sure all the requirements were accurately represented. Users should also be involved in the design process, since they can provide feedback on usability. Sometimes what you think is a great UI will fall flat because users don't understand certain features. I've never had a project manager get involved in UI, but every team is different.
As far as the skills of the person developing the UI - It's not unusual to find a graphic/web designer who has development experience, so they will be able to create the designs and integrate them into the application. Depending on the project size you may have different UI roles. One project I worked on had a graphic designer, a usability / 508 expert, and a "UI integrator" (basically a front end developer). If there is no money for UI people, I guess the task would fall to a developer. I've worked with programmers who claim they "don't do UI" and they won't even touch presentation code, but I think any programmer who works on a platform that has UI needs to be able to do front end work.
This is for the User Experience Team. They should have tested a design, copy (text) and all of the other stuff well before you see the design or final layout.
Depending on the technology, the UI will be designed either by a programmer or a graphical designer or both, based on scetches of the program owner, a product manager or the end user.
It will always be the user that accepts or declines and therefore decides on a user interface. Hopefully not after shipping by just ignoring the application or solution.
Ideally, someone with formal training in interface and interaction design should be the one designing the UI. Nowadays, this is a discipline in its own right, with its basis in (graphic) design, psychology, ergonomics, communication sciences, perhaps even software engineering, etc. This does not mean that this person is the only one that deals with the user interface, as various stakeholders may have influences:
The boss may enforce some decisions based on strategic choices or financial considerations
Marketing may enforce some decisions based on product management
The customer may have peculiar wishes that he demands get implemented
The developers may have a certain style or preference
Common UI element, specific icons, logos, etc. may be designed by a graphic designer
But ultimately, it should be the UI expert that combines all these inputs and designs the UI.
Of course in practice, it depends very much on the size of the software company. A very large company can have their own department for user interface / user experience issues, whereas in a small company, the task usually goes to whoever is deemed best at it.
In any size company, you can take the chain of command and move up, to see who has the last say, and the reverse holds true for who will do it.
In an ideal world the Presentation layer is the responsibility of the analysis and design team. There are a lot of theoretical and practical uses to a UI, which a simple designer may have never been taught. That does not go to say that a designer with a brain - or experience - will not generate more than adequate results.
Bottom line: there is no right answer for a design. Even if you have a checklist of things that a good UI should include, there is always the aesthetic aspect of it, which is not really quantitative.
No better approach than trial and error. Even Google Adsense/Analytics encourages you to make multiple designs, and alternate between them while collecting statistics which are quantitative.
Given your question, I am guessing you do not work in a large company, otherwise your job description would have been well defined.
So: Stop whining and just do it!
UI design is a joint responisbility. UI Design is not just a flair for graphic design
It involves the clients, users, some with flair for graphic design and developers. You even review the UI which is done by someone other than the designer & asking stack overflow users' thoughts on a specific design brings us into the equation.
Generally, all people are responsible and one or a couple of people should be involved in the process from first contact with the client to final delivery on the system.
communication skills, flair for design (lo-fi or hi-fi), objectivity, being able to take criticism and analytical ability are all required.
The extent of applying these skills will vary by company & project size.
Graphic design flair means you could possibly get a great looking UI that is not usable.
I agree that UI design is a collaborative effort. In my experience graphic designers or user interaction experts create great mockups which ultimately get bastardized by managers and developers. If you have a UI concept that you want to get added, make sure to justify every aspect of your design.
Here is a basic idea of how the UI evolves in my MASSIVE software company.
Managers dictate a 1 or 2 sentence requirement.
Dev team develops feature
Graphic designer comes up with UI based on managers crappy description
Dev team bastardizes the graphic designers UI
Management completely changes their mind
Repeat step 2-5 at least three times
Release a Beta
Beta users and product reviewers feedback drive the final UI
Do not underestimate a good beta. You could make all the graphic or user interaction designers in the world happy; ultimately it's the consumers that buy your product.
How a UI looks should be guided by the user interface design guidelines. If your organization doesn't have guidelines lines it would be great to start on one.
The UI Guidelines ideally should be put together by a Visual designer (Theme) with help from an Interaction designer (behavior). So the answer is what colors should be there are answered by the Visual designer and what it should/ shouldn't not do by an interaction designer.
In real world all kinds of roles have a say in the interface. What we call stakeholders. From strategy guys, to marketing people, down to project management people. The nest to quite them all is to prepare guidelines that direct.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm facing developing a new web app in the future and I'm wondering how to decide what framework to use. I've settled on Python as my language of choice. But there are still may frameworks to choose from! More generally how do you choose between different similar technologies that are still in the works as the latest round of web frameworks are? I'm curious what your process is for deciding on technologies you've never used.
Recognize that no choice is perfect -- or even very good.
No matter what you choose, someone will have a suggestion that -- they claim -- is better.
No matter what you choose, some part of your tech. stack will fail to live up to your expectations.
The most important thing is "shared nothing" so that the components can be replaced.
After that, the next most important thing is automatically-generated features to reduce or prevent programming.
Look at Django. Lots of automatic admin features make life very pleasant.
There are a number of things you can do:
Download the frameworks and build something similar with them for comparison.
Look for comparisons by other people, but attempt to understand the bias of the reviewer.
Observe the community at work, see what people are building and the issues they run into when using the technology. Forums, blogs, mailing list etc are good places to check out.
Go to conferences and meet like minded developers interested.
You can also take the approach of using stable versions rather than alpha bits. After a while you might move closer the bleeding edge. People associated with the project in question are generally more biased than those approaching from other platforms, be careful who you trust.
Consider the impact of using a bleeding edge framework versus an established one. Sometimes it's important to your customers that you are on one perceived as stable. At other times this doesn't matter. How comfortable are you with fixing the framework itself? Great developers will learn the internals, or at least know enough to keep things moving whilst a bug is sent to the framework mailing list etc.
Consider some general best practices in building abstractions and reusable code on the python platform. You may be able to save yourself some work in moving to another platform. However, don't be a reuse junkie as this can limit the effectiveness of your use of the framework. The 37Signals guys are right when they talk about extracting frameworks from working code rather than building frameworks from scratch.
I know this is an old posting, but I am in a similar situation (again) and I think there are other people who may want to look for different opinions, and hear of (somewhat) successful experiences.
Since baudtack mentioned Python, I will try to answer this along the lines of my experiences using Python. Here is what has been working for me:
determine the scope of your project - outlining what your application is supposed to be able to do without introducing any programming or design notes will clarify your goals greatly
determine how you would like to work with your code, stack and data:
a. what sort of programming paradigm do you want to work with? i.e. object-oriented, functional, etc. do you want to play to your programming style or do you want to follow somebody else's programming style?
b. use semantic web or not? do you want greater control over URIs and their design? (I found web.py great for this by the way - It is my choice to create REST APIs in Python)
c. do you want to be trapped by framework requirements, or do you want a better separation of the application from the web component, i.e. use a framework to utilize your application as a set of modules, for example. My problem with Django was that I ended up not programming Python, but having to learn more Django than I needed to. If that works for you, then that is the way to go.
d. data stores... some sort of SQL vs. non RDBMS (xml databases like eXist-db with full xquery support) vs. OODBMS vs. a combination of the above? how complicated do you need this to be? how much control/separation do you need to have over how data gets stored and recalled in your application?
e. testing: unit tests... thank goodness for python! if your web app has the potential to grow (as they often do), having a sane and coherent testing platform to begin with will help out a lot in the future - I wish I had learned about this earlier on. oh well... better late than never.
f. how much control over the server do you need? hosting considerations? how much control over an Apache instance do you need to have? OS specific needs? I found that using shared hosting providers like Webfaction has been great. I eventually found I needed greater needs for flexibility and bandwidth. In other words, what can you get for your budget? If you have USD50 to spend each month, it may be better to consider a virtual hosting solution like Linode....
Finally, I echo S.Lott's sentiments that no choice for a solution is perfect, and are subject to obsolescence.
Experience trumps hearsay. I've found that prototyping is a huge help. Make a prototype that uses the features you expect to be the most important for various frameworks. This helps route out any features that may not work "as advertised."
In general though, kudos for being willing to look at new technologies.
I have a set of criteria in different categories:
Activity & Documentation
Is there an active user base?
Is there an active development base?
Is the support responsive and information accessible?
Are there user and development guides and reference material?
These are essential, there needs to be traceability of all of these to build confidence in the solution.
Ease of use
Are basic features easy and complex features possible? I typically give a new framework a test drive and try to roll out a set of use cases to see how intuitive the framework is to use.
Is installation intuitive and simple for a local/dev installation and production deployment?
How is it backed up and upgraded?
What is the effort and UX for implementing a "Hello World" type blog post, static page, menu item, and plugin?
How are versions dealt with for the core & plugins?
Example (on the topic of Automated Testing/Continuous Integration solutions)
Several years ago I evaluated several Automated Testing solution. At the time Jenkins and TeamCity were front runners and in the end I chose TeamCity because of the UX, active user & development base and quality of accessible documentation.
Example (CMS for a blog)
This criteria is also why I prefer to use Wordpress over other options. While wordpress has its shortcomings, the user and development base is strong and active which leads to a software architecture with more potential to evolve over time and maintain its relevance and a development community that provides quality plugins and themes to choose from.
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 have been looking for a collaborative tool for developing functional specifications. I am looking for the ability to:
Have multiple users contribute to the specification.
Provide some form of traceability, which could be done manually if needed.
Provide users with the ability to add comments and notes.
Upload and display Visio documents
Upload and display mockup screens using Balsamiq Mockup.
My initial impression is that using a wiki could be a good tool for this task. Does anyone have experience with using a wiki for creating functional specifications? What would be the pros and cons to using a tool like this as opposed to a requirements management tool?
Your input is greatly appreciated!
It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
There's no feedback loop to make sure the writing actually gets done.
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.
"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.
Consider researching Fog Bugz. They tout themselves as the best of the
best for project management. Considering Joel's history I'd give them the
benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious.
Depending on the size of your project, buying it might be a very good
option.
At very least you could look at how they've structured it, or read the
forums for ideas on how to build your own stripped down version
Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Things can creep and get off-track quickly
Communication can be lost in the medium
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!
We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
a table defining requirements attributes,
which creates interactive forms with field selection and validation (where you can also document discussions and rationales, embed images, attach documents, link to other requirements...),
and then queries on these "requirements" and show them as tables that can be sorted, filtered, printed, reported against, etc. (e.g., http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.
As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.
I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions...
The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....
This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.