Let me know when you're going to link to PyDraft; I really ought to make sure it's in a good state first. --CH
Better export page. One "Export" link with several links/buttons to export in XML, plain text for copying (with or without headers), plain text for downloading (true plaintext .txt file), BBcode, Mediawiki, and CSV.
Preview Card button on new card and edit card pages.
L/M * User Preferences: always display plaintext; suppress highlight and/or addressing; image vs HTML; cardlist columns to show/hide (comments, code); card view/edit columns to show/hide (code, active) L/H * Session memory of where you were (I already have some of this wrt signing in; repurpose it to return from "edit card" view to previous page) + M/L * Config option for default state of comments by admins (distinct from default state of comments by other users). M/H * Set "nicknames" for users, sets, cards - for more meaningful URLs
If you do this, it may be worth having nested routing. At present, the URL for an Arcunda card has no indication it's from Arcunda rather than, say, Sienira --CH
Yeah, I considered nested routing before, and didn't want to deal with the refactoring, but I should just do it. --AC
M/H * Mailing list for each cardset; subscribe to a cardset for instant / daily emails H/M * Better help: "How Do I" do X, including modify several cards at once. Describe images etc. Transclude and expand the help for set skeletons. H/H * Record previous revisions of cards, perhaps using paper_trail H/H * Integration with MSE, or export to its format. M/M * Allow users to provide text etc to go on their user profile page (comes with spam risk) M/M * Allow some mechanic parameters to be hidden (supports Amplify, Reminisce, Hierarchy) M/M * Live JS preview of marked-down comment text as you type it
Put your feature suggestion here!
A diff-view for when things change. Obviously, this would be painful on the database, so you may wish to consider ways of mitigating that; perhaps you could only keep a diff for Details pages, and/or only keep one historical revision (so you can only see "latest diff"). If the latter, perhaps it'd be best to enable a "minor change" box (or equivalently a "start recording diff" button) in case you make a change, then realise you forgot something and make another change immediately. --CH
This I think is equivalent to the potential feature listed above, "Record previous revisions of cards, perhaps using paper_trail". I've been shy of it for database space reasons, as you suggest. (Data point: the current database with 48 cardsets, 3000 cards, 2500 comments is ~850Kb. Heroku free database limit is 5 Mb.) However, the idea of keeping just one diff has some merit. I might have it be a 24-hour diff to avoid the problems you mention of minor edits. I'll give that some thought. --AC
How does a 24-hour diff work? If it's rolling, you probably have similar database issues. Or you could grab a snapshot of the last day at midnight every day, but that doubles your database when most objects won't care... --CH
I haven't thought through the algorithm in detail, but I'm thinking something like: card has_one previous_card. When I receive a new version of a card, look at the last-update date on the current version and the currently stored previous_card. If the current card has been edited less than 24 hours ago, leave previous version as it is. Otherwise update previous version to the current state of the card, before applying the new updates. A nightly diff would be another nice option - if I can find a way to schedule a task to run every night, then it could delete the previous_card for everything that hasn't changed in the past day. I'm sure Heroku must provide some way to do that kind of thing. --AC
Worth considering, yeah. My JS sortable-table library provides the browser-side Ajax for free if I can make its Ajax requests talk to the server. --AC
Oh, didn't spot that was scriptaculous itself. That makes it more likely there'll be simple guides to make it work smoothly with Rails. Cool. --AC
Search box for card-text searches the raw text only. This means that when finding cards with given mechanics, you have to specify the placeholder name. Be nice if it could search the "rendered" text, but I realise that's probably Hard. --CH
Yup. It would indeed be nice, and it would indeed be hard, because it's a direct (escaped) SQL query, and I don't store rendered text. I could do; it'd balloon the DB size a bit though. I could perhaps only store it for cards which have a mechanic on them, but it'd still slow down searching a bit... hmm. I'll give it some thought. --AC
First seach all the mechanics for the term, add any results to the search qeury and search the cards as now. --Vitenka
That's a very sensible idea. Admittedly it doesn't help if someone searches for "Flying, triple strike" and there's a mechanic with display name "triple strike" but codename "threeness", because that card'll be in the database as "Flying, [threeness]". But that's a fairly unusual case. So yeah, your proposal would be one of the easier options to fit most use cases. --AC
From ToothyChat: Make mechanics sharable between sets. Perhaps on the "Add mechanic" screen, have a two-stage dropdown list to import mechanics from other sets.
+ A random card button on the homepage or somesuch that will show a random card from the entire site. Or even better, a 'random booster pack' button that will generate a pack with any of the cards on the site, mixing anyone's sets into a single pack (like an MtGO? beta test booster pack, or a cube draft pack). This could be a fun crazy thing to see, plus it is a way to showcase several random contributions all on one screen.