Is there any documentation that explains each class in foundation.css? I am not great at front-end development and don't seem to be grasping the concepts with just cursory documentation available on zurb's site. Thanks in advance.
There is none. I think it will be tough for them, the ZURBlings, and overly-exhausting for us, to go over it, documented. I think what you need to know is what Responsive Design is all about. You can have a good beginner's introduction here:
From Wikipedia - a bird's eye
view
Another bird's eye view of
RD
Then continue on reading what Foundation is basically about.
And once you have a broader knowledge of what RD and Foundation is basically about, you can go crazy about it here and learn that it can actually allow you do more.
You really need to learn about their css once you are comfortable using Foundation, having read the links I gave you, and want to start to tweaking some of the configuration - which by the way is already explained in their docs.
AFAIK, there is no document that explains each and every class, but you can try to look at the kitchensink
http://foundation.zurb.com/docs/v/4.3.2/components/kitchen-sink.html
They have (almost) every component available as a demo in a single page. So you could inspect each of these elements and familiarize yourself with the class names.
This applies only to F4, I don't see a kitchen sink in F5
Related
I want to do something a bit like they have on IMDb - every film and every person has a forum dedicated just to them. I also want to have a forum on the main message boards, which would show all the threads from the film pages and another forum for all the threads from the people pages.
I've been looking at DjangoBB, Dinette and Sphene (SCT). DjangoBB looks like it has the most features and it's very elegant. Dinette doesn't seem that far behind. Sphene has a few disadvantages - less features I think and it makes me dependent on Sphene's Community app, but it seems like it might be the easiest to use in my scenario - I've seen examples of Sphene being used in similar fashion.
I'm pretty sure all three can be made to do more or less what I want, but would love some opinions on what might work best for me.
Another thing to consider: you could just use django-threadedcomments. It won't be as full-featured as installing a full forum solution, but has the advantage of being very compact and flexible -- basically, threaded comments can be attached to anything (a Person, a Film, etc).
It appears that DjangoBB and Dinette are not set up so that forums could attach themselves to a record in this fashion. Not sure about Sphene but it sounds like you'd have to use the entire community app.
I've set up a very, very simple Discussion app that could perform what you want. If you're interested let me know and I'll put it up on github for you to take a look at. Note that it's not at all full-featured like the ones you mentioned.
A bit late to answer this, but I think it might be worth mentioning The Pinax Project, which is django-based and is geared toward rapid development of social websites with many applications integrated together and customizeable at the user-level.
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 11 years ago.
Improve this question
What features should "Tomorrow's" wikis include? How might they incorporate Web 2.0 features like AJAX? What other features are they currently missing? What do you want to see from the next release of your favorite Wiki?
Edit: How might a Wiki be integrated into other products? What "neat uses" could wikis have?
Preview-as-you-type works very nicely indeed here on Stack Overflow. Many wikis don't do that.
Make it really easy to link between pages, eg. that, as you type, the wiki finds likely pages you may be referring to. That way you can make links without having to know the exact title of a target page, and bouncing on the shift key to WriteInCamelCase, or throwing in square brackets. Make it very easy to link to other websites outside the wiki, too (and by "easy" I do not mean like wikisisters, which, if I remember correctly, is like foowiki:ALinkLikeThis).
Similarly, if you can generate links within text automatically, you could, for example, have a mail system that wikifies your email. You create a wiki page, say, for Joel Spolsky, and references to Joel emails in your inbox become links to that page, which you can find by clicking "what links here". (This probably needs something along the lines of Bayesian filtering to prune the stray references to other Joels... your Bayesian Classifier learns that if the context is smart and getting things done, it's Spolsky. If it's flying Viking kittens, it's morely likely Joel Veich).
A variety of RSS feeds for tracking changes would nice, too. (Diffs, full text, changes on pages I've edited, ...)
Wikipedia has grown a fairly colossal categorisation system ("Fictional Cats", anyone?); laying a taxonomy over a wiki's flat namespace could provide another way for users to find their way around. Wikipedia's doing this a little, but in fairly limited ways so far: there are links to the relevant category lists, but you can't, for example, look for a composer called "Smith".
Similarly, wikis give you this big graph of interconnected nodes, of how closely your community sees the relevant concepts as being. Is that interesting? Is that useful? Does anyone who isn't google want to think about this stuff?
PS. If you believe Paul Graham's definition of Web 2.0 as "Democracy, Don't Maltreat Users, and Javascript works now", wikis are two thirds Web 2.0 already.
I am personally already tired of wikis. Wiki as a software is outdated, now it is about wiki as a feature (like my favorite new website, stack overflow).
The main advantage of community wiki — more editing — came into existence when we introduced "Suggested Edits".
With "Suggested Edits", anyone, even an anonymous user, can edit anything — so long as another experienced user reviews and approves their edit.
I'm in the process of choosing a wiki tool, and have looked at numerous packages over the past week. I'm sure there are dozens I haven't even heard of yet, probably good ones. But in general, here's my "beginner's mind" take on the problem.
Wiki markup should be abandoned. A wiki that is limited to wiki markup will only be useful to 'nix hacks and others who get excited about doing things the hard way and insisting that everybody else is stupid. I mean, Morse code is fine with me personally; I don't get what was wrong with a nice, clean dash-dot-dash. Or smoke signals, they were nice, except for the carbon footprint. But times change, and we have to change with them.
Real users (business users, customers, clients) want rich text editing. Period. And when a wiki tries to support both rich text and wiki markup, the results are not pretty. The model is confusing and (apparently) difficult to implement. The fckeditor extension at wikiwiki is a nightmare, for example. It's just not worth it.
Wikis need better access control. The idea that all content should be open to everyone is fine for an open, public, non-profit wiki like this one. But in the business world, that's not how it works. Restricting access is not evil, it's reality. Wiki tools need to do a much better job of providing access control: access to pages and groups of pages based on role or group membership, where groups can be formed by anyone on an ad hoc basis and users can belong to multiple groups and pages can be accessible to multiple groups, at the whim of the page's creator.
Those are the two things that I want, above all else, and I haven't found it in open source, at least not out of the box. Which, of course, is why open source is open source.
There's been some interesting work using wikis for testing and software development. EG, movement towards literate programming -- allowing pages to exist as both code and documentation that is compiled down into one or the other (or, I suppose, both simultaneously).
They have a regular session about this at the annual WikiSym conference.
I think one direction of Wikis is going from open ended collections of documents to an "everyone can edit but with more structure" applications like SO.
Another direction that I've seen is more direct integration with other project support tools, so project planning, issue management, and all that stuff.
Personally, I think the next big direction is going to be some sort of multimedia based Wiki, not just a Wiki where multimedia can be embedded in the text.
I really like MediaWiki. It's widely used and free/Free. The markup syntax is straightforward and allows you to do enough basic styling that you don't need to use custom HTML or to use a WYSIWYG. I assume by "sexy web 2.0" you mean Flash/AJAX, but I like MediaWiki because it works cleanly with basic HTML/Javascript (you don't have to wait for custom widgets to load, etc...).
What makes wikis reach their potential of usefulness is the community that develops around them more than the software itself. You need to find a niche where people are both passionate about (but not criminally insane about) the central topic and have enough technical prowess to log on to a website and edit some text.
"Wiki" is ultimately just a pattern:
Open editing by all/most visitors
Integrated revision tracking and rollback to reduce the cost of mistakes
Simple syntax for cross-linking between articles, and auto-creation of stub articles when referenced
That's not a perfect description, but it's a combination that isn't particularly magic. Successful wikis combine those things with a critical mass of people creating and maintaining content.
The next step, IMO, is less about web 2.0 shininess and more about the integration of better structural information. Adding any metadata beyond "this points to that" is an exercise in brute force hand-markup. Maybe microformats? Maybe the development of more structured knowledgebase software that uses wiki-ish editing UI but a smarter backend? I'm not sure, but I think better handling of the structured data is really the next wave.
Extensibility.
Check out DekiWiki, they are doing an excellent job with this.
DekiWiki extensions
The wiki-of-the-future will be completely editable online, concurrently by everyone. Check out EtherPad for a demo of the techonology.
For me, in terms of Enterprise style uses for a wiki, I have a couple of thoughts;
An effective way to keep and synchronise a central, web based wiki with multiple, offline, desktop style wiki's for people on the go
To move towards wiki as a function as opposed to wiki as a system, so we can integrate the wiki collaborative system into other things
Could some one point to articles / books on how to create good flow chart diagrams?
BoUML-it's free!
I've used this open source tool for the last 6 months at work to create UML diagrams:
bouml.free.fr/
I've used it on both a Macbook running OS X, as well as Ubuntu Linux on a desktop, both with success. It also does codegen (although I haven't used this feature myself). If you create a diagram from within BoUML, you can right click ->Tools->HTML etc,etc., and it and actually generate the diagram -- this will create a whole tree of html, css, etc., and include a .png file which you can later choose to import into a Word-like document.
If you're new to UML, and would like to explore that route, I suggest UML Distilled by Martin Fowler as a way to quickly ramp up. I still use this as a reference when I'm putting diagrams together and I forget some syntactical detail ;) The nice thing about UML is that most programmers will understand it. If you don't want to buy a book you can, of course, Google 'UML tutorial' and get a slew of free info.
Non-UML:
You can also use open office's draw application to do some simple flow charting. It has some nice non-uml shapes, so if you're not trying to be 'strict' in the sense of conforming to UML, and just want a simple flow chart, that may be a good choice.
Check this one out:
http://drakon-editor.sourceforge.net/DRAKON.pdf
Tutorial here.
Also get a copy of Microsoft Visio.
Do you use a wiki in your company? Who uses it and what for. Do you share information between projects / teams / departments or not?
We use ours to store
Coding Style docs
Setup and Deployment procedures for web servers and sites
Network diagrams (what are all the servers in Dev, Staging, QA and Production called etc.)
Project docs (pdfs, visios, excel, docs, etc.) are stored in SVN. For the non-techies we have links to those docs in the wiki that point to an up-to-date share on my box. (tip: some wikis provide source control integration but ours doesn't)
Installation and Setup procedures for development tools
Howto's on things like using our bug tracking system, our unit testing philosophy
When doing research on a topic I often capture the important information in a wiki page for others to learn from
I've seen them used to keep seating charts in medium to large size organizations for the new people
At my previous company all of the emergency contacts and procedures for handling a critical outage where available on the front page of the wiki
The best part about a wiki is that it's searchable. Some wiki's support searching inside uploaded or linked docs as well.
If you setup a wiki and encourage or even require people to use it the amount of information that will accumulate can be amazing. It's definately worth the effort especially if you have someone in IT with some spare time on their hands to set it up.
Do you use a wiki in your company?
= We use it for the purpose of a Knowlede Based. Basically it is a wiki but many more functionalities intagrated.
Who uses it and what for
= Employees. Knowledge Sharing, Preparation of collaborative-documents, etc.
Do you share information between projects / teams / departments or not?
= Depends on the requirements. It is possible to set permissions between users.
We use a wiki, for documenting our systems. It's updated gradually as things update and evolve. It should go without saying that there's benefit in that, however whether you use a wiki or other methods is worth thinking about.
A wiki is great for collarborative editing. The information shouldn't go stale in theory, because as people use the systems they have the opportunity to keep it up to date.
However we have found in our organisation that people struggle a little with wiki markup. Especially tables. I think a solution that has wysiwyg editing would be better if you have non-highly-technical people editing it. Sharepoint springs to mind, but it's expensive.
I use a wiki as my virtual "story wall" for agile development. All of my stories are written and organized in the wiki. While my customers are reasonably local (we can have face-to-face meetings), they aren't co-located. To enable better customer interaction I've resorted to a wiki instead of a wall-based story tracking mechanism. It also works a little better for me due to the fact that I often have multiple, concurrent projects and limited wall space in my cube. In a larger team with more focused projects and more wall area, I'm not sure I'd make the same choice.
My company uses a wiki for project-planing but also for storing documentation and ideas.
I have found that a wiki is a great way to link the programmers in the company with the business-people.
When someone who are not on the programming-team comes up with an idea or finds a bug, it's a loot simpler to let that person document it in the wiki.
I think it's an important aspect for a small company like mine to easily synchronize the business-team with the development-team. A wiki helps with that, since it gives the feeling of being a part of the development process, instead of having to ask the programmer directly about every little detail.
we have MediaWiki to store technical information that is not ready to be published in other formats - specification drafts, diagrams (via GraphViz extension), results of short investigations, etc.
I also think this question is a wiki too :)
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 9 years ago.
Improve this question
I was recently put in charge of the wiki for the development team. The wiki is still in its infancy, so I have a lot of room to work with. It goal is to house internal to the development team. Currently, the main piece of information that the wiki holds is Coding Standards.
What are some best practices your dev team uses for its internal wiki?
What information is important to have on a dev wiki?
If you were to go to the wiki for your dev team what information would you expect to see?
Is there some information that shouldn't go on the wiki even though it seems like a good idea?
-- edit --
Also, is there a good way to organize the information? ( such as by layer ( data, ui), by porject, or other)
Introduction to the source base for new programmers
General documentation (not the API documentation per-se, but more tutorial like things)
Lists of staff / who's doing what and how to reach them
Notes / resources / articles that explain concepts used in the software
Documentation of the build process and the filesystem layout of the codebase
Other things I usually put up there are
Planning / todo lists
Information that is interesting for others to read
Everything else that I feel should be shared
We had a development wiki and it was a great tool. We used it for everything!
When brainstorming new ideas, we'd capture them on the wiki. The low friction nature of the wiki made it easy for anyone in the organization (we were a small startup) to add ideas as they thought of them. We had a high level "brainstorming" page which linked to detailed pages containing a thorough description of each idea.
For each iteration, we'd "move" feature idea items from the "brainstorming" list to the feature list for that iteration. The details of the feature were flushed out to include design and implementation details.
As features were completed, the iteration page became our release notes page - which also included the release tag from our version control system.
We had a bug page that worked very similar to the feature pages. Bug fixes were added to the iteration/release pages as they were worked on/complete.
We also created our user documentation on the wiki and exported those pages it with the release.
As time went on. This tool was viewed more and more valuable. We wound up creating new wikis for different the products the company was working on.
I hope you find your development wiki as useful as we did!
Wikipatterns is a website dedicated to documenting best wiki practices. They also describe anti-patterns and talk about ways to deal with them. I read their book and it was a great asset for me to get a wiki off the ground in a 150+ person organization.
One thing that we stress on our dev wiki is that it is updated when things change.
We don't want our wiki that is intended to provide information and be a central source of collected knowledge to become so out of date that it is useless. As the code is updated, developers are requested to update any related information on the wiki.
Other than Coding Standards, we keep tips and tricks for working with our code base, setup information for new hires, and general environment information.
The hardest part is getting developers to use your wiki. I have some long standing suggestions here: http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted
Getting a Wiki Adopted is Tough
Have a Champion
Remove Objections
Create Content
Enmesh the Wiki In Company Processes
Evangelize
Don't Give Up
Consider Not Using Wiki For Conversations
Just Do It! Don't Wait For a Budget
Have a Transition Plan
Promoting Your Wiki
One good practice is to have the entire documentation and source code for each build available through your wiki. Then developers will go to wiki to access build info and that makes it invaluable.
Wikis can be a valuable resource for software development teams but they are not a silver bullet. It is all too easy to create a Wiki that would rapidly fall into disuse or become grossly outdated.
In my opinion, the key to a successful Wiki is getting the entire team on board. That means getting people away from other resources (and in particular email archives) as knowledge repositories, and offering some incentive for people to contribute.
However, it's also important to not be a format czar: If you have a lot of documents that you generate in, say, MS WORD, it may be ideal to do them all in Wiki format but that takes time and may be annoying if you have diagrams, documents, etc. In those cases, it's better to compromise and let people keep it in word format, as long as the only way to access the newest version is through the Wiki.
If you're not a manager, you need to get a manager on board because it would require some "enforcement".
There has been accumulating research and experience on Wikis and their use in software engineering. You can search the ACM digital library, for example. I am a coorganizer of an annual workshop on wikis for SE and we had several interesting experience reports and there are additional materials in the international symposium on Wikis.
Burndown charts
common setup information for development environments (nice for when new people start)
Specs
Known issues and workarounds with development tools
Come up with some kind of style guide, and teach others how to style stuff. When I was in charge of a corporate wiki, all of the other developers would just write crummy prose that was barely formatted, and looked terrible.
Keep away from things that require discussion. I tried shoehorn in a book review section, but it was too difficult to have others comment on things.
Examples of in house libraries are good. And/or "storyboards" walking a user through a process when MethodX is called.
What are some best practices your dev team uses for its internal wiki?
Make it look nice. I know it doesn't sound important, but if you spend a little time branding it pays off in terms of people actually using it. And uptake is key, or it will just wither and die.
What information is important to have on a dev wiki?
General information about a Project, milestones, delivery dates etc.
Summaries of design decisions/meetings. Important so that you don't re-visit the same areas time and time again.
HowTo guides for general development of current projects (for example, how to develop a new Plugin)
If you were to go to the wiki for your dev team what information would you expect to see?
Project information, who is working on what etc. Design decisions. Also best practices and links to useful sites.
Is there some information that shouldn't go on the wiki even though it seems like a good idea?
Low-level task lists tend to fluctuate and not be kept up-to-date, and can be misleading.
Also, critical communications between departments are better suited to e-mail, THEN the conversation can be copied to the wiki. It's too easy to ignore it otherwise!
Remember that a wiki is interactive. If you're thinking about publishing, as in publishing burndown charts, then you're not thinking far enough. Distributing that information is only part of it.
For instance, rather than having a "Current Burndown Chart" page, create a page for "Burndown Chart for Week of 10-27-2008" and then encourage people to comment on the chart, and what it means, and why you did so poorly that week.
We house and inhouse team wiki. And there we put all the necessary information for each project we are developing:
repositories
addresses for virtual machines
passwords
project documentations
project overview
project status
and anything else we fill needs to be written on a project. And it is the most useful web application we are running (besides Mantis) . On more general pages we put a definition of every taxonomy we are using, general project guidelines, polices, coding and developing practices we use.
It is there, it is simple and effective and I think every team should have one of those.