Fan made projects related to MLP

Search /collab/ threads

Name  
Email  
Subject  
Message  
File     
Embed    
Password  (for post and file deletion)

File 132980381982.png - (383.95KB , 2835x2835 , 132641954273.png )
34386 No. 34386
This aims to be a replacement and improvement upon /fic/, in that it will provide both intuitive and well-structured software-level means to facilitate peer review of written works and ideas (fanfiction in our case), but also an advanced registration-is-optional web forum for discussion of fanfiction, literature and writing in general.

Preface
Firstly, to all who posted in the original thread in /fic/, I am truly very sorry, but meaning to report the thread to have it moved to /collab/, I accidentally deleted it. I am still reeling with frustration and shame that I have lost all the opinions and input of everypony.

Model
This is based loosely upon my ideas so far in addition to some suggestions that have been made. The relational map: http://bit.ly/A2XARX

In a nutshell: every comment, review, request, story and thread OP will be a post or a subclass thereof. The idea behind this is to make one unified reporting, changelog and this-is-in-response-to system and one CRUD (create, read, update and delete) for parcels of submitted text on the website, and then reuse it by extending it with other models based upon it. Minimum re-writing of code by keeping it D.R.Y. and such.

General Layout / Design
As for the view (the naming scheme not necessarily as follows) there are four navigational tabs:
1. Discussion, in which people could make threads about writing, character development, etc.;
2. Generals, which opens a dropdown menu pointing to threads that are large enough to generate continuous discussion may be placed. Threads made in the discussion area that fall under a general's category can be tacked on to the thread as posts. The menu header itself points to a view akin to the discussion area.
3. Exchange, under which there is a menu with three items each corresponding to a queue-like view. In each of these "queues", requests would show up similar to threads but omitting responses, with a simple symbolic indicator (i.e. color and a number) to indicate they have responses, if the submitter got what they were asking for, etc. (or we could even use AJAX/jQuery to give them expand buttons that show responses to requests). The three categories of requests (three sub-menus) would be:
--- Reviewing, people submitting fanfics for review. Chapter updates in stories could be submitted as requests, and they would show up in the queue as well as in their respective story thread. Responses would show up in both places as well, only in the review queue they'd be hidden, whereas in their respective threads they would show up as responses to that individual post (or just the OP).
--- Story ideas, where people get feedback on story ideas. Basically, use the model of The Training Grounds and the Reviewing queue mentioned above and apply it to Story Forge.
--- Recommendation/Request, same idea as Story ideas and Reviewing. People can ask quick questions about fanfics, ask for recommended reading, etc.
4. Projects, which would serve as a repository for story project threads. Stories would be fancy versions of threads, but with special features. For example:
--- In the OP, the links to each chapter could be displayed. When the author submits a new chapter, that list could be automatically updated, by integrating the add-a-chapter feature into the posting method itself.
--- Chapters could be marked as reviewed/preread/proofread, and given markings by the authors as they come back to update their story as such.
--- People who read and give critique would be given the option of a star rating, and the author / other users could contest it based on whether they think it is fair / well-thought-out, unlike the star rating system on EqD where people can just proclaim "ZOMG FILLY [Alicorn name]" or some remark of that ilk and gush 5 stars, or "ew, death and desolation" and punch 1 star. This was actually samurai anon's idea.

Other miscellaneous features / remarks:
--- There would be clear, link-based direction to the proper form to submit a request for help on a fanfiction (or either of the other two requests) versus creating a thread in the discussion area (this is perhaps THE most important feature)
--- Longer threads could be paginated, with links to each page number and a little number box for specifying posts per page.
--- Every user would have a view associated with them, with tabs displaying a history of ther posts of each different type (review, review request, story idea feedback, project thread updates, etc).
--- You might ask, "why have story projects AND review queue." The answer lies in choice of display. The reviewing queue makes it easy to find things that haven't gotten any views or feedback. The project thread area is for showcasing the projects and their related discussion. Every story could be in either place, but there would in essence be one "object" (or rather, one thread object, with one project and one request object tied to it) with all the information in the OP displayed in both places. Sound fair?
--- We need some sort of updater, i.e. that will take an uploaded zip file and update the whole website. That will make it so that we can get something basic up and running, and then improve on it and install the new version later.
--- Indentation for comments that are in response to another comment. If a comment is in response to nothing, it can be left non-indented, but if it is in response to a non-response it becomes indented and gets tacked onto the end of it, and if it is in response to a response, it merely inherits the indentation and association of that comment. That way, little discussions and spats can be self-contained and allow the thread to continue (as such lines of commenting wouldn't show up among the latest posts at the end), not to mention making it WAY easier to follow and pick up on the context of the discussion so that if people flank in, they're less likely to make fools of themselves.
14 posts omitted. Last 50 shown. Unspoiler all text  • Expand all images  • Reveal spoilers
>> No. 34504
File 132992862314.gif - (188.99KB , 400x372 , twi-collate.gif )
34504
You know what? USER STORIES MAY BEGIN AT ANY TIME. You don't have to wait for me to do all the organization, categorizing and condensing of ideas that we have so far. It's more fun than "hey it should be able to do this should happen."

First, some good news:

1. I found out how to embed a Google Document read-only in a page:
<iframe src="https://docs.google.com/document/preview?hgd=1&amp;id=[document ID goes here]" width="850" height="1000" title="Embedded Doc" frameborder="0"></iframe>

This shall make the website a fine interface for presenting stories. With some AJAX magic we could have the iframes pop out with a "+" button so that people could read chapters without leaving the website.

2. While !!Celestia still hasn't gotten back to me regarding the deleted thread, it turns out I had the thread open in Dolphin. So, naturally, from that page buffer I was able to select all the text and copy it to elsewhere for safekeeping. It will take some time to clean up, but nothing of value was lost.

Okay, back to business: if you are interested, please do start writing user stories now. Write a short story of a person interacting with the website and other people, describing what they do at each step of the process and what features of the website they use. See >>34388 for the role of this exercise.

User roles/prompts
--- A Guest (not logged in, unregistered)
--- A Registered user
--- A Moderator
--- An Admin (can promote users to mod status, and has access to certain CRUD actions that moderators don't)
--- SysOp (can promote moderators to admins, and has permission to perform any and all website actions)

Some suggested scenarios
Please don't limit yourself to these; they're really simplistic and obviously non-comprehensive:
--- Requesting feedback
--- Post reporting
--- Posting a story, and adding chapters
--- Asking for a second opinion after receiving feedback
--- Merging threads / posts into general threads
--- Settling user conflicts
--- etc.
>> No. 34519
>>34504
Aside from
> terse short stories about different users doing different things, having different roles on the website ,
I'm still not really sure what one of these user stories would look like, could you provide an example [or a more detailed description]?
>> No. 34529
>>34519
Here's what could serve as the opening sentence of a user story:

"(username), a (Guest|User|Moderator|Administrator|SysOp), goes to (action). S/He goes to the (view), which displays (features). S/He then (interaction) the (controls/features), and (result)."

You could start even simpler, with a one-step feature request, and use the template:

"I, as a (Guest|User|Moderator|Administrator|SysOp), want (feature) when (context/circumstances).
>> No. 34578
I, as a guest, want to be able to post my work with the fewest amount of steps possible, but still have the ability to edit or delete my submission if I so choose.
>> No. 34592
File 133008991948.png - (276.08KB , 640x359 , cbd3bc39574c8284d24f9251453a18c3.png )
34592
I know some HTML/Javascript/PHP and I'd love to help! I am not advanced by any means, but I've managed to pull off the features of http://www.ponycontent.com/ in not too much time. I have very little experience in using GitHub, but I would love to learn and have that experience. And I know some OO methodology. Let me know if I can do anything aside from the use cases prior to the base app being setup.
>> No. 34630
Right. It's the end of a long hard week, I just got out of the shower after a day of scrapes and welts from airsoft with my coworkers, and I'm a bit sore but have some time now. Time to get down to business.

First, compiling the list of ideas/feature requests.

Then, the post model. It will best be the one piece of the puzzle that doesn't change. That's because, for the sake of versatility and re-use of code, it should be made the Swiss army knife of persistent data -- but also because if we decide to change the model later on, it will involve a buck-ton of SQL rejiggering. So, some careful planning is in order.

>>34592
Any help would be great. Just remember we're not building an airplane from scratch, like MacGuyver, but we're building one from a kit - and the end result will perform better and be safer.
>> No. 34631
I'm thinking of completely scrapping the idea of giving unregistered users their own page (specifically, a "user" object with associated views) that lists all their reviews, posts, stories, etc. for the reason that if that user changes their posting handle there would be the problem of having to tie every post, thread, etc. associated with their old handle with their new handle, which would require changing the userID of all those posts and... Oh my god it's complicated. I don't have brainspace to pander to people who can't be bothered to register to the extent that they are nearly indistinguishable from registered users. So, people who don't register get only the same sort of functionality they'd receive from a no-reg message board like Kusaba, with the exception of being able to create requests. Their handle in posts would, instead of linking to a user profile, open up some sort of search-by-posting-name view.
>> No. 34633
And in regard to images:

We're going to use free 3rd party hosting, i.e. imgur, to cut down on costs and bandwidth, right? Well, check this out:
http://imgur.com/tos
> Don't upload copyrighted material, harassment, spam, gore, pornography, or anything that looks like pornography. If you do, we will ban you along with the site you're hotlinking from
How about only registered users can post with images from imgur? Any parasprite could in less than five button clicks / key commands make imgur unusable to every user on the site.
>> No. 34640
>>34631
Don't give guests a user page.

Guests will have access to as many features as they do here: posting, deleting, (and editing). I don't think they need nor want more than that.

Now, the post class: if you're logged in, you aren't prompted for a password when making or manipulating posts. The manipulation of your posts can be verified by your user ID instead. (I think this has already been said.) Any post a user makes has their ID as a property, any guest has their password.

My user story: https://docs.google.com/document/d/1ZzsE2-YqJClh_KrhHD1LDCTRBC8QWVRmtXcYZhV9KWc/edit

Basically, if you post as a user, your posts will be linked to your user page, your user page will link to your post, etc. for nice archiving of information. However, there is a tickbox (or some other form of modifying your submission a la the email field on Kusaba) that you can use to make the public association of the post with your account invisible. This way you can "post anon" while still logged in. The post would still be privately associated with your account in the database for post manipulation purposes.

The display name will be an extra field on post submission, defaulted to "Anonymous" for guests and $user_name for users.
>> No. 34643
File 133014422927.jpg - (12.58KB , 325x332 , veruca_salt.jpg )
34643
>>34640
Thank you again for your input! And, that story was entertaining.

> Now, the post class: if you're logged in, you aren't prompted for a password when making or manipulating posts. The manipulation of your posts can be verified by your user ID instead. (I think this has already been said.) Any post a user makes has their ID as a property, any guest has their password.
Good to know there's somepony around here who can read my mind. I just wrote this into the model outline five minutes ago (though not in those words).

Here are a few very simple "I want ____" user stories I came up with:

I, as a SysOp, want to be able to temporarily disable guest actions site-wide (a constant defined somewhere, perhaps)
I, as a Moderator +, User who is the author of a post, or Guest who has the password to a Guest-created post, want to be able to not merely delete a post or thread, but to have it moved off to a "quarantine" zone (pending deletion) that only Moderator+ users can view, and retain all the necessary data so that if need be, it can be restored.
I, as a User, want to be able to add chapter links to my story as a part of the editing feature. The links, if to Google Documents images, would (via AJAX) open up an iframe rendering a preview of the document so that it could be viewed inline, without leaving the website.
I, as a Moderator +, want to see IP addresses displayed on Guest posts, with a "ban" button / ban expiration time field next to them which would block the IP address from posting.

Now, as for this:

> However, there is a tickbox (or some other form of modifying your submission a la the email field on Kusaba) that you can use to make the public association of the post with your account invisible. This way you can "post anon" while still logged in. The post would still be privately associated with your account in the database for post manipulation purposes.
Um... Hmm... Challenge accepted.

I got it!

The post class has a Boolean attribute, "stealth." In every view involving the post class (except the user view), the user ID is omitted from the post in every way if True (except if the viewing user is that user). However, in the user's view: if the viewing user's ID matches that of the viewed user's ID, or the viewing user is Moderator+, the post ID metadata and a "stealth" tag would be included. Otherwise, a blank post with "redacted" and stuff (and the post ID completely omitted, so there's no way anypony else can find the post) would be displayed.
>> No. 34649
A couple of suggestion and thoughts I had:

1.) I believe the layout for the website should follow something along the lines of this place:
http://www.ponyfictionarchive.net/index.php

Which, as lacking as it might be in the graphical design department, actually is a good base for all the things which the project tries to get done. With some fiddling with the layout, you have the queue showing the oldest entries in the queue, you have a special queue which I call the Karma queue (but more about that in a minute), you have a bar for special announcements and highlights you might feel inclined to do, you have the major categories with their pop-up menus. Put simply, an improve layout, graphics and modified search engine would do all the things we want with as little complications as possible. If I understand correctly, we are currently going more for the same sort of system we have now, with threads and the sort, which seems to me to be unnecessary once you consider something like what is on that website would allow all the discussions and the rest be run like a forum, but the actual reviewing, commenting, selecting, processing, and the rest, be run by an easy to understand list. Even if you want to expand the scope beyond merely reviewing (I personally find the idea of hosting the stories to be both unnecessary considering there are many other methods available, but perhaps the notion of applying the same construction to ideas would be helpful as well), the layout there seems to be to be the best one. Plus, this way the whole issue with the mature stories has already a solution, you press a button to go to that sub-domain and do your reviewing there. Now mature fics have a place where the very few that would bother can go in an organized fashion, cause those are stories too.

2.) The system might benefit greatly from the implementation of a visible system of points which would increase or decrease as the contributions of any given person increase, decrease, and are judged. Reviewing other’s stories, showing good improvement after receiving reviews, helping out others with their stories by commenting, and in general interacting positively and correctly with the website will increase the “karma” you have, in representation of how much good you have done. The karma points will be a testament to your participation, your experience with writing, your willingness to listen to advice, and just simply your value to the community. The specifics of how much karma you would gain from any given action (reviewing should receive the most karma, simply commenting the least if at all, you lose karma if your advice post isn’t actually helpful or you just insulted him for, like, twelve paragraphs, or you are just paraspriting and star-bombing), but that can be worked out as we go along. Apart from the respect this will derive from others, and hopefully those who have high marks be example to follow, I figure other perks should include:

-the front page will have a special queue where the projects of those with the higher karma ratings will have an increased chance of appearing related to how high their karma points might be. The whole point is for it to be random, but have the stories which need help from those with higher karma points be more likely to be chosen. This is all done with the notion that if you contributed a lot with the community it isn’t too far-fetched to make the community help you out.

-with the rated critiques (a bit more on this later), the rating placed by registered users will be weighted in relationship to their different karma ratings, the higher the karma the higher the proportion of the final rating it would be ( grab the persons karma, divide by the total karma between all the registered users, the resulting percentage times your rating is the portion of the total rating). This is done with the assumption a person which has a high karma will have more experience in writing and thus would know better what to look for. Think of this as the way to prevent the place from becoming fanfiction.net with a funny name

-periodic congratulation notes to those who just reached a certain amount of karma points, so people know that others are indeed getting recogniztion for doing the job, and thus making people say “if he did it, I can too”

-require a certain amount of karma points for anypony who is going to be a particular level within the organization (mods need 500 karma points, whatever) so that people that feel the need to take over first have to make contributions before being able to tell others what to do.

So just in general being more active makes you feel like you are getting somewhere.

3.) Couple of ideas related to rated critiques, reviews, and the sort:

-limit the number of reviews to three or two for any given iteration, so that people are given a number of times they can go and keep it unchanged while still having other people review it (as in, you have three reviews? Better make sure you update it with the fixes or you can’t add it to any queue). This should make sure that people don’t simply wait for somepony to tell them they’re right, because somepony eventually will tell them they are right and that kinda defeats the point of reviews. Also, with the limit in place, it makes sure the next thing comes into play. Additionally, perhaps make the anon critiques not count towards the limit or the official rating, but still be present if perhaps they have some insight into how to improve the story. This will have a two-fold effect: if somepony goes and says he appreciated your comment, but you can’t have anything to show for it because you are anon, you might feel encourage to join and register so that you can have more recognition for your help, and it will also prevent people from coming in and star-bombing without being able to know who was star-bombing and banning them for it.

-keep a progress bar of sorts for how much a story improves ratings from update to update, making sure to color code by the relationship (amount of improvement/number of revisions). This would work in an interesting fashion, because you could then see the graph, see the critiques, and be able to evaluate both if the author is listening to the reviewers (and thus the reviews he was given are the problem), or if he is not (making him be the problem). Whichever it is, it gives a sort of transparency and self-correction so that everypony knows who is not putting in the effort

-make the addition to any particular queue be based upon request rather than be a given so that a person can cop-out from being in the main queue while still being part of a personal queue. So, you would have the little box which would say “general queue” and you would decide if you want it there or not. So, if you click it, you would be sending a request to the general queue to be added, but you wouldn’t need to be accepted because the general queue would accept anything as long as it’s not mature.

I have other things, but none are as developed.
>> No. 34650
File 133015211253.jpg - (90.52KB , 634x343 , 120602 - glasses hipster i_liked_cider_before_it_got_commercial rainbow_dash.jpg )
34650
>>34640
If $user_name is just the default, how do we stop users (or anons for that matter) from impersonating other registered users? Here, that's done with an optional tripcode. Since most Gummii users will be registered, there's no real sense in that... unless the tripcode is the actual unique username, and every post can have a per-post-configurable display name? Ugh, that just sounds needlessly convoluted. I'd vote for locked usernames, like most sites with registered users.

If we're going to allow anon posting, that tickbox is probably best. My cynical side tells me that allowing users to post anonymously will lead to flame wars, but in practice /fic/ seems awfully civil, I suppose...

>Is preaching against anon users on a chan board
>Acknowledges he's in the minority
>Acknowledges that meeting Ponychan users halfway will be necessary, if we want TTG to move to Gummii. Particularly as we have noteworthy anons.
>w/e, Devil's Advocate

Okay, user stories! I meant to do this earlier tonight, but let's see what I can do before I nod off.

>I, as a Mod, want to be able to see every story rating that user Bob has given. I also want a button that can remove all of Bob's ratings [anti-starbombing measure, idea stolen from EqD Prereader thread]
>I, as a user, wrote a smutty Octavia/Bon Bon clopfic last night after one too many Cosmopolitans. User Bob has favorited this fic, added it to his watchlist, offered to review it, has posted a review for it [and any other means of tying his user acct to my fic]. I delete my abomination, which should cause it to disappear from all of Bob's aforementioned views. [The possible exception is maybe preserving Bob's completed review... debatable point]
>I, as a user, only like grimdark. I want Gummii to remember this preference, and only show grimdark by default when I go to the story search page [obviously, still allowing me to change this option before searching... just a default]
>I, as a user, wrote another alternate ending to Cupcakes (mine is actually good!). I want to somehow indicate this [directly make this a response to the original fic? A Cupcakes group or fan-ring that I can add my story into?]
>I, as a mod, can undo the previous setting [unparent, remove from ring] if it's completely irrelevant [prevents popular fics from having unrelated responses who are just desperate for views]
>I, as a user, upload a story via a GDocs link. Gummii will automatically generate the word count [dependent on GDocs' API supporting this]
>I, as a user, upload a story via a GDocs link, and attempt to set its status to Review. Gummii will automatically verify that comments are enabled [dependent on GDocs' API supporting this]
>I, as a user, want to optionally indicate whether my in-progress fic will eventually be 2 chapters or 200 chapters once finished. User Bob should be able to see this metadata when searching for reviews [assists with reviewer matchmaking]
>I, as a user, want to indicate if my fic is in-progress or complete.
>I, as a user, when viewing a story, would like to see related stories [idea stolen from FimFiction. Appears to be generated by "those who favorited this also favorited..."]
>I, as a user, want to provide keywords for my story [i.e. the 5 words that EqD asks you for, assists with search function]
>I, as a user, want to search for stories based on major characters
>I, as a user, want to be able to report a story to mods. The report form should probably have a category dropdown [incorrect tagging, incorrect fan-ring/parent, inappropriate as per site rules, etc] with a textbox to allow me to specify the offense.
>I, as a user, want to be able to give my story an age rating, with an option field to explain what content justifies the rating [ex. NC-17, for sex and tubs of jelly]
>[Not a story because it needs discussion: what formats of story upload are acceptable? GDoc url? FimFiction url? Uploading from a .txt or .doc? Our own built-in editor? The built-in editor, obviously, gives us all the features we want but is infinitely harder than any other option. GDoc has the best adding-comments support of the options listed, but now we're potentially forcing users to create both a Gummii account and a GDoc account]
>I, as a user, want to be able to add a chapter to an existing story of mine.
>I, as a user, want to be able to modify an existing chapter in a story of mine.
>I, as a mod, want to be able to disable commenting [not sure if this deletes/hides all existing comments or not] on a story/user/review/etc.
>I, as a user, want to be able to send private messages to other users.
>I, as a mod, want to be able to remove [not sure if this is deleting, or simply unpublishing] a story (or review) that has been reported. User Bob, who is the author (or reviewer) will receive a private message notifying him that it has been removed, with a small text field explaining why.
>I, as a mod, want to be able to see all disciplinary actions that user Bob has received, so I know if I should swing the banhammer. [Some actions may auto-generate an entry here. Mods should be able to manually add entries here as well.]
>I, as the admin, want to customize the category tags [Shipping, Grimdark, etc. If we're intending this for use by other fandoms, they'll want flexibility]
>I, as a user, want to be able to respond to my reviewer Bob. This includes a text message and a rating [review was helpful/not helpful]. Bob will receive a private message when this occurs. Bob and I will both be able to reply further on this "thread" as desired. I will only be able to apply one rating to the entire "thread", not one rating per post.
>I, as a user, will have a visible reviewer rating, which shows how many reviews I have done, my aggregate rating, and links to all my past reviews.
>I, as a user, want to be able to check user Bob's userpage and see his queue of pending reviews.
>I, as a user, want to be able to send a form request to user Bob asking him to review my fic, with an optional text message.

zzz
>> No. 34651
>>34649
>karma
I'm a bit skeptical of these types of things. The devil is in the details, and when you say:
>The specifics of how much karma you would gain from any given action ... can be worked out as we go along
I'm a bit skeptical of this resulting in karma being more important than actually being a healthy contributor.

I'm not a bit fan of a number whose fundamental purpose is to say, "My worth here is more than yours."

Concernfagging out of the way, a good implementation could very well do the exact opposite of my fears and prompt more active contribution.
>> No. 34653
>>34650
>impersonation
If somepony is logged in, all their posts will be accompanied by their user ID and a link to their user page/profile/whatever. Think the email field here on Kusaba, except instead of linking to an email it links to the user's page.

The display name is just a string for view purposes. So, for example, anypony could have a display name "RogerDodger", but nopony (except me) can post with a link to RogerDodger's profile.
>> No. 34657
File 133016214688.png - (419.00KB , 1024x1048 , 132641877486.png )
34657
Oh wow. Suddenly, an explosion of ideas! Me gusta.

>>34649
Thank you, Anonymous, for your well-articulated ideas.
> 1.) I believe the layout for the website should follow something along the lines of this place:
> http://www.ponyfictionarchive.net/index.php
I wholeheartedly agree on a technical ground; a front page that grants an overview of site-wide information, updates and new material is pretty much obligatory.

> If I understand correctly, we are currently going more for the same sort of system we have now, with threads and the sort, which seems to me to be unnecessary once you consider something like what is on that website would allow all the discussions and the rest be run like a forum, but the actual reviewing, commenting, selecting, processing, and the rest, be run by an easy to understand list.
That is exactly what I am proposing. When I speak of everything being a post, I mean that in the sense of re-using code, not in a structural manner.

> mature stories
I'm not touching that one with a 50-ft cat5e cable. Don't get me wrong, it could be useful to have a non-public projects area (i.e. for technical/academic peer review, wherein there is users who might want to keep things out of the public eye). However, out of principle, I'll say that I do not think we should work on such a feature solely for the purposes of being inclusive towards "mature" fics. Instead, reviewers who are willing should provide their email and notice on their profiles saying they're willing to review fics via email exchanges. It matters not to me if it is virtuous to open the doors to such material, if even for maybe just one insightfully-written adult content story among droves and droves of the most grotesque and juvenile clopory writing on the internet. It's a massive PR liability to have that kind of shit sitting on the server. That being said, I'll have you know that if I were in charge of a website running this software, and the necessary feature were implemented, I would completely eschew and forbid its use for the said purpose.

> karma points
I am really, really liking this idea - or at least, what it promises. The greatest challenge lies in coming up with an implementation that does not result in some people gaming such a system or being able to abuse it, which they WILL try to do. After all, what we are dealing with here is a totally abstract, numerical reduction of personal impressions, and one that is used in AUTOMATICALLY passing judgment on all parties that it applies to, not to mention automatically giving others an impression of an individual (to the extent that they trust the points system is accurate). So, I will try to take this advice, especially considering I've heard a very similar idea from somepony who I respect ;-) , but with caution. This WILL be the most complicated aspect of the system's logic if it is implemented. Thus, I hope you stick around and continue offering insight as you are able, because reconciling the idea with the model will be difficult, and I may need your help and advice. One thing:
> the front page will have a special queue where the projects of those with the higher karma ratings will have an increased chance of appearing related to how high their karma points might be
Those who have zero points (newcomers) should have a default ratio/rating, so that they could still be given a spot.

> limit the number of reviews to three or two for any given iteration
Nope. Or, at least, it could be circumvented as easily as cycling power on one's DSL modem, since no authentication/sign-in is required. Hence, how (besides an IP address) would we identify a Guest user? You might say "the name they post under" but that introduces, once again, the complications of creating user handle records for every guest user, to identify them and make the connection between request objects. Furthermore, if they want, they can always just change the name they post under and get around it. I guess the general point that needs to be conveyed here is that not all the mechanics of human interaction on an anonymous message board can be handled by automation. The easiest way I can imagine to solve the problem of people who don't care about improvement but just want a hug and a cookie is the ability to very easily search for the title of the fanfic among the active records. Also, there's the human element on our side; requests, being post objects in essence, could be reported/deleted/etc if they're redundant.

> Additionally, perhaps make the anon critiques not count towards the limit or the official rating, but still be present if perhaps they have some insight into how to improve the story.
What we could do is add a report tag (category of report) to posts contain well-deserved and well-articulated praise or admonition from a Guest user, to a registered user. Then, a moderator could, in response to it, give it an associated karma points rating that applies to the person in question. There should ideally in all things be checks and balances, and the logic should give anonymous users less power to immediately enact changes in the persistent data of the website. That way is more secure, I believe.

> if somepony goes and says he appreciated your comment, but you can’t have anything to show for it because you are anon, you might feel encourage to join and register so that you can have more recognition for your help
Again, there is the very real problem of identification. How can we be certain that a person who registers is the same person as the anon, and not just any person who is trying to take the reputation of the former anon? Also, wouldn't the process of registration and transferral of Karma require manually chasing down every last thoughtful critique ever made by that user who never bothered to make a persistent user account so we could track and trace their critiques in a straightforward manner in the first place? I tell you, you have very good ideas in principle, but some of them I can forsee being an absolute nightmare to implement in practice.

> keep a progress bar of sorts for how much a story improves ratings from update to update
I am loving this idea. We could do AMAZING things with JQplot.
http://www.jqplot.com/
The data attribute for tracking score and keeping count could be a part of the "project" model.

> -make the addition to any particular queue ... general queue would accept anything as long as it’s not mature.
Could you please elaborate or describe it differently? I don't quite understand you here.
>> No. 34658
File 133016229538.png - (555.11KB , 1024x777 , 132641189188.png )
34658
>>34650
Thank you, thank you, and thank you immensely for so many user stories. I read through them all and they ranged from simple and very important to incredible yet complicated yet not impossible to implement. Having them all will help me to remember to make note of them. I'm still working on planning out the
post
model ;-;
. One thing I'm excited about is how my idea for creating metadata objects tied to posts, to give them a certain function (i.e. as story projects, requests or discussion threads) could very easily accomodate your idea for keeping Bob's review despite you having deleted your abomination. The way it could work is that, upon deletion of a story (or rather, "removal" - more on that later) the critiques, as post objects, could be disassociated with the story project and left as "orphaned"; since they do not appear in any thread or story's post lists, the post of Bob's critique wouldn't show up anywhere except in his profile, and the data, still being present, would remain his own.

> how do we stop users (or anons for that matter) from impersonating other registered users?
I have had the solution to this in my mind for quite some time. It involves writing a custom validation action;
http://www.yiiframework.com/wiki/168/create-your-own-validation-rule/
This action could, during the post submission, perform a quick indexed search through usernames (the index being rebuilt each time a user registers). If no match exists, the posting name attribute passes validation, and if all other attributes validate as well, the submission goes through.

I do also want to include the tripcode functionality, even for registered users, because it's fun and easy enough to implement. I just found this:
http://avimedia.livejournal.com/1583.html

> unless the tripcode is the actual unique username, and every post can have a per-post-configurable display name? Ugh, that just sounds needlessly convoluted
Tell me about it. I was thinking about making persistent guest records, but since any guest could simply post under another user, the database could get swamped if a group decides to parasprite/raid. Furthermore, there would be the challenge of making an action to tie all the posts made under all the guest's different posting names together.
>> No. 34659
File 133016244624.gif - (122.89KB , 218x290 , spoiler.gif )
34659
>>34657
> droves of the most grotesque and juvenile clopory writing on the internet
Fucking word filter god fucking dammit.

Mast herb hate ory
>> No. 34677
>>34657
>not in a structural manner
Thank goodness. Imageboard are nice and all, but it seems like creating a website so it's a review image board to be waste of time.

>mature stories
I'll agree it's probably a touchy subject, but I guess you are going to let other people use your layout so that they can implement it themselves? I mean, if current repository for mature stories had a system like this I'm sure we wouldn't be having as many... ehmm... senseless rackets going about. Still, maybe keeping a safe distance might be a good idea.

>Those who have zero points (newcomers) should have a default ratio/rating, so that they could still be given a spot.
Ehmm... I was thinking along the lines of having the list of all stories, but making the randomizer have the story of a high-karma reviewer repeat as many times as determined by a formula (one repetition for every 200 karma points or something), so if there are ten stories, but one of the guys has 425 karma points the effective random list would be twelve stories, with three of those listed being the karma guy story. That way, in the long term the karma guys appear more often, but in effective term it’s still technically random. Dunno why you would need a default rating, unless you want to give everypony the benefit of the doubt and then let them lose karma points by making bad posts?

>The rest
I have no idea what you are talking about. I simply said that if you, the anon, found out people like your critiques, you would feel more willing to review with an actual name and thus have your evaluation actually count for something. That critique you just made is water under the park (although, I guess you could erased it and post it under your new name, so the renaming is less of a renaming and more of a repost...), if you want future critiques to count, you get a name, but those old critiques will stay happily anonymous and there is nothing you can do about it. Yeah, trying to change all those sounds like a waste of time, and having the opportunity to do that would actually make so that you don't actually need to make an account to get credit until you bother to do it, which seems counter-productive, but that is not what I'm talking about. To explain:

> limit the number of reviews to three or two for any given iteration
With this, I am saying that the project (story or whatever) has a maximum of three or two slots for registered to put on their critiques per update. So, I make "For I Found myself where I was Lost", a long, epic, adventure-filled, deconstruction of transforming into an alicorn (female one too), and falling in love with Carrot Cake, version 1.0. Now, I put it into the general queue and also request it to be personally reviewed by Sgt. Sprinkles and Madmax (don't shoot!), where in all three places I get my review and I'm told that I write like a 13-year-old girl with daddy issues stemming from a long line of abuse because my father hated English and decided to make me have horrible grammar. At this point I wouldn't be able to put it in any queue (although I should probably still be able to search for my story in the system) because I already have three people telling me what to fix and I have done nothing to do so. Now, after getting help from a psychologist, facing my father and forcing to learn to read, reading a couple of guides about writing, I come back with a new version of the story. Maybe I rewrote the whole thing, so it's now V 2.0, or maybe I just fixed the sentence and its V 1.1. Either way, until I update the story saying I fixed it (and getting burned by the gods if I didn't), I won't be allowed to return back to the queues because then we will just be the pre-readers rereading the same mistake ridden text like drunk flounders, but we can't seriously expect to use a three strike rule to tell people to stop coming back with the story essentially the same if we are going to be the reviewing site of the fandom (this is the first of its kind I think, in any fandom). I have no idea how this involves identity, unless you are going to allow people to erase their projects and present them as brand-new, never reviewed ones, which will only bring problems because then all those reviews are lost, the person learned nothing, and they are just hunting for praise (FiMfiction and fanfiction.net have us covered on that).

> Additionally, perhaps make the anon critiques not count towards the limit or the official rating, but still be present if perhaps they have some insight into how to improve the story.
This is just meant to prevent a bunch of anons coming in, spamming a story with critiques, and then having to deal with the mess of erasing those critiques for the author to get the help he wants. Assuming we don’t have any limits to the amount of critiques that count, anons could still come over and bomb a story with very little one could do to stop them if their critiques weren’t treated differently. If there is a limit, anons could come over, fill all the slots, and then the person is removed from the queues because of a group of parasprites. If only registered users critiques count towards the limit and the ratings as I said, the anons are just a minor annoyance that can be erased rather than a serious clogging problem we can only expect to come. Basically, this is a proactive anti-parasprite measure against the paraspriting that anonymity will foster, while still allowing good useful anons to remain. Win-Win-Lose (the author-those who want to help him-the parasprites).

>Also, wouldn't the process of registration and transferral of Karma require manually chasing down every last thoughtful critique ever made by that user who never bothered to make a persistent user account so we could track and trace their critiques in a straightforward manner in the first place?
Again, that ship has sailed. The idea is that if you see suddenly a thousand people saying that your critiques are awesome, you see that you will never get your name to that critique, that other guys are even getting recognition for doing this thing you did for free, and the only thing stopping you from doing the same is inventing a character so you can lurk around the website, making your brilliance shake the earth, you are probably gonna want to register. That's it, no name changing, post chasing, madness inducing mumbo-jumbo, just nudging people to want to do things with a little bit more accountability. You will never get those karma points; I repeat, you will NEVER get those karma points from the critique.


On that token, I am seeing anon posted stories by unregisered users, allowing changes to be done by putting in a password to make sure the same person is doing the changes. I presume this means that you will allow somepony to change a story so it’s under an specific user? I mean, if I'm an anon, I decide I like the website, and then want people to keep working on my two-hundred chapter human-turn-female alicorn love epic with rainbow dash as the zoidberg, I might want to have that ability. I mean, it should be too much trouble to change the owner of stories, right? Of course, doing so for comments, critiques, and the rest would be insane, but allowing people to do so with stories seems practical and logical.
>> No. 34678
>The whole karma deal
I am just saying I can’t make it myself from scratch, because I am not that certain what would be more valuable, how you would judge it, and ultimately what would be the limit. This website should foster reviewing and improving one owns stories, both activities which everypony will have to be involved in. The second one ain’t that difficult to calculate, just give an amount equivalent to how much the story/chapter is improved and how fast (actual formula might need some tinkering, but I don’t see why you couldn’t work something simple). The first one is a bit trickier, but I’m currently just running with: have a certain specific amount of karma points per story reviewed (with some sort of multiplier for longer stories?) which would then be awarded 60% if the person found it fair and helpful, and 40% if the community found it fair and helpful, keeping a check and balance on everypony involved as the community would still give the reviewer his due if they thought he was actually helpful, but the reviewee didn’t (all this terminology is confusing…). Additionally, making it more helpful than the other ones might get you more karma points, reviewing first also gets you a bonus, etc. That way, we make people find that reviewing is the fastest way to gain Karma points, but will only gain them if they are actually helping people. Plus, to make sure people do get involved in the judging of the whole thing, we can make it like other karma systems and make commenting, voting on fairness, and all that gig give you very small amount of karma points. This of course considers that each object under your name has an intrinsic karma value, if you get your comment deleted for some reason then you lose them (aka, you were first, but your review is terrible and insulting, so a mod erases it so you don’t take up space with your failure). So, pulling numbers out of thin air.

Assuming fair means helpful in this context:

-You review and everypony agrees your review was fair/ only the author think it was fair/ only the community thinks that it was fair/ no one thinks it was fair: 30 points/ 18 points/ 12 points/ -5 points (cancels out the “you reviewed first” bonus)

-You reviewed it first: 10 points

-Your review was considered the most/second most/third most helpful by most users (if there are only two, the maximum you can get is ten, and so on): 15 points/10 points/5 points

-You improved your story after receiving a review: currently working with the formula (∆r^2)/n , where ∆r is the change in rating and the n is the number of revisions. This of course means that if you made a story, got a rating of 1, then came back with it revised and it got a 10, you would be getting 81 karma points in one swift move. Sounds like a lot doesn’t it? Here is where we must be careful to mod such things, as if a person is constantly coming in with terrible fics to then return back with the stolen Shakespearean play of Twilight’s we might have karma gaming, which should be grounds for banning

-You make a comment: you get a point, assuming people don’t down-vote your comment.

-You help the evaluation of critiques: you get a point.

That’s a pretty crude instrument I build right there, it probably full of broken scenarios and possible gaming, but the point is to show how, more or less, it would work.

Also, it might be obvious, but what the hay: only registered users can actually do any of these things, anons don’t get the privilege of influencing the karma system.
>> No. 34680
I'm liking this karma idea, and not only because of the much-needed meaning it should lend to numerical ratings if implemented well. It's human nature to enjoy watching numbers going up and bars getting filled, and if well-implemented, a karma system can be a great psychological motivator for people to help out and do a good job of giving and receiving critique.

I wrote about fifteen works of flashfiction on a site that had an experience meter that would go up based on judgement of creative output done in response to prompts. Numbers and bars work.

User stories (well, only three, but I'll try to think of more that haven't been covered):
https://docs.google.com/document/d/1X7qhpQCXab4vPZGfKuWvymsZUjjjtdMugq4fb60F1kI/edit
>> No. 34693
>>34677
> I have no idea how this involves identity
Right, let me break this down to you in a way you will understand.

An imageboard such as the one we're posting on right now is completely and utterly stateless/agnostic in regard to a user's posting history. That's because the concept of "users" is completely nonexistent; it's no-registration, with the exception of mods and admins. As such, it allows people to change their names, their tripcodes, their post passwords and everything on a total whim, with little to no consequence to the functioning of the website except the addition of one more post.

What you (if you are the same anon as >>34649) were proposing would in essence require the creation of a record in a database to keep track of every single "poster", which is an extremely tenuous concept at best when it comes to non-registration posting that can include anon posters. What this could translate to is the creation of hundreds and hundreds of records that serve absolutely no purpose because the user chose to post with a different name/tripcode or under a different IP address. That's why your ideas are completely and utterly impractical unless restricted to registered users; it would be very easy to circumvent the very purpose of keeping track of guest posters in the first place (to assign karma to them), not to mention trashing the database with records that do little more than consume disk space.

> Dunno why you would need a default rating, unless you want to give everypony the benefit of the doubt and then let them lose karma points by making bad posts?
Exactly. If only people with high karma points were displayed front and center, newcomers would be overlooked more often than not, driving them away.

> unless you are going to allow people to erase their projects and present them as brand-new, never reviewed ones, which will only bring problems because then all those reviews are lost, the person learned nothing, and they are just hunting for praise (FiMfiction and fanfiction.net have us covered on that).
I have an idea that would allow people to erase their works yet still have the critiques remain.
If you have any ideas for how to preventing this sort of thing on a message board that does not require registration, then I'm all ears. But seriously, if registration isn't required, then there's absolutely no barrier to users doing exactly this.

I'll respond to the rest of your post later, after I get some more work done on planning this whole thing out with everypony's ideas and suggestions.
>> No. 34695
Right, I hadn't finished reading before I responded to the earlier parts of your post, and thus didn't catch how you had already conceded that assigning "karma" to anons is absolute nonsense (because there's no sure-fire way of identifying them, of course). So, please excuse my ranting. I'm just trying to keep this as simple as I can. Having thought it through a bit, it would be antagonistic to that goal to attempt to please a demographic that is more often the very worst group of +rolls who would visit the site, versus consisting of rare anonymous individuals like yourself (insightful, patient and willing to offer well-articulated opinion/critique).

> If only registered users critiques count towards the limit and the ratings as I said, the anons are just a minor annoyance that can be erased rather than a serious clogging problem we can only expect to come.
We're on the same page; >>34657
> What we could do is add a report tag (category of report) to posts contain well-deserved and well-articulated praise or admonition from a Guest user, to a registered user. Then, a moderator could, in response to it, give it an associated karma points rating that applies to the person in question. There should ideally in all things be checks and balances, and the logic should give anonymous users less power to immediately enact changes in the persistent data of the website.
So basically, anons couldn't fill requests, but registered users (or guests, with the password to their original request post) could report the critiques if they were helpful and they're satisfied, and then a mod could mark them as resolved. Thanks to you (?--again, if you're >>34649) we have finally found a middle ground in the problem/issue of the request-fill-resolve logic that would be +roll-proof (for the most part). So, I would like to sincerely thank you for that.

> I mean, if I'm an anon, I decide I like the website, and then want people to keep working on my two-hundred chapter human-turn-female alicorn love epic with rainbow dash as the zoidberg, I might want to have that ability. I mean, it should be too much trouble to change the owner of stories, right? Of course, doing so for comments, critiques, and the rest would be insane, but allowing people to do so with stories seems practical and logical.
Again, the concept of "user" is really vague if they're not registered and it can result in clutter/mess if one were to attempt keeping track of them all.

Every other presentation-oriented site requires registration to present stories. Why not this one? For something really high-end like a project thread that will have lots of extra creature comforts, it would be a huge loss to the user if they misplaced/forgot the post password and couldn't come back to edit it. How then would we identify them, if they emailed an administrator asking them to change / reset the password, versus some +roll who just wants to trash the story's page? The story thread would effectively be dead, because the poster didn't retain the password. If a person is registered, on the other hand, their account is tied to an email, and they can always reset their password.

Again, it's totally impractical to give Anonymous users too much power and functionality. Basic post editing and request usage would suffice; most of the time people come to /fic/ asking for critique, so that's what they can easily get without having to register. So, Y.A.G.N.I. -- but also, if we encouraged people to register and kept the assignment/retainment of karma points to registered users, we wouldn't have to worry about doing so for nonregistered users, as it is a feature that's geared towards people who have a vested interest in the community to begin with (and why, if that's the case, they wouldn't bother to register -- especially considering it's easy to make a throwaway email account -- strikes me as very odd).
>> No. 34697
>>34680
> story 1
Duly noted. "Subscription" feature for registered users - both to project threads and to the activity of other users.

> story 2
Awesome, I've already thought of a way to accommodate this (see my remarks here: >>34658)

> story 3
Could be done. The "feedback" object could also be granted a tags attribute, so reviewees would know what they're getting, and reviewers could put what kind of review they do into their profile pages. As for advanced searching and filtering, that's practically obligatory.

Thanks for the input!
>> No. 34719
File 133029826863.png - (1.23MB , 1280x768 , 138901 - artist raikoh14 derpy_hooves.png )
34719
Many posts to reply to... handle it!

>Mature fics
I'm inclined to go the PFA model too. It keeps all the mature fics separated, all the reviewers who want to do mature fics can look in a separate place, nopony will accidentally stumble across them. Plus, if we don't have a mature section, that just means people will post mature fics anyway regardless if it violates site rules, so more work for the mods. All that said, I don't personally partake, so I don't have a horse in that race.

>Karma
I do like the idea of rewarding reviewers who are generously sacrificing their time. I also like the idea of rewarding writers who actually respond well to criticism (>>/fic/82380, sweet tapdancing Lyra). I absolutely agree that new users should not get shafted by the system; we don't want this to be perceived like an Old Boys' Club, where a seasoned reviewer can skip their story right to the front of the line.

I do like the idea of a reward system, even if it has zero functionality. As a reviewer, getting 5/5 stars for review usefulness is always a nice touch.

>Progress
I like >>34649 's idea for a progress meter, showing how each revision of a story gets closer to ready. EqD prereaders would likely also love this The question is how. Every reviewer could review their revision in a vacuum, certainly, but opinions will vary; one reviewer's 90% may be another reviewer's 20%. This would only be possible if a reviewer was able to see the present revision, as well as the previous revision and all comments there. That's only possible if the story is hosted locally inside Gummii. That's only possible if Gummii has its own basic text editor with support for adding comments :(

I think ultimately, to get everything we'd want, a text editor in Gummii is the right answer. That shoots up the order of complexity substantially though, so I'm inclined to say "phase 2".

>Various Anon things
>>34653
This just means that we'd have multiple RogerDodger running around, with one of them having a small icon labeling them as "real".
>>34658
That would prevent future occurances, but not past. So I might register and make a welcome post, only to find out that everypony assumes I'm the same person as the guest user who was posting under that name until recently.

I still don't see the value. But, I'm already well-on-record for that point, and it sounds like the point is getting good discussion, so I won't hammer any further on it.

>>34680
I like these! More on the "writer stalker" feature below. I also think the idea about tags for "what do you want me to review"/"what am I good at reviewing" would help matchmaking. I could see a situation where I hypothetically wrote a LyraBon shipfic. One reviewer gave me very excellent grammar and style suggestions, but they weren't a LyraBon fan, so they couldn't assess if I was keeping them in-character. I might want to resubmit my story to the queue, but indicate that I only really want an OOC check.

>Queues
I see what >>34677 is saying. We definitely don't want a user to send their story into the personal queues of 50 different users. There's definitely a "too many cooks in the kitchen" situation, and it just wastes people's time. Some users (like, idk... ShortSkirts) might have a larger stable of reviewers, but Ezn's suggestion about reviewers being able to stalk writers would help address that. I'd also add:
-- Reviewers who get a story request added to their personal queue can obviously turn it down. They should also be able to see any other pending/completed reviews. If they see that 50 other people are currently reviewing it, they can turn it down.
-- If my story is in one or more personal review queues (whether because I sent it to them, or because they grabbed it off the general queue), I can't simultaneously add it to the general queue. There's not much sense in getting additional eyes on a story at that point. If all my reviews come back and I feel I need additional help (on this or a future revision), only then can I readd it to the general queue.
>> No. 34734
So I tried planning out the logic on my own. I failed. Well, I failed to get much further than planning through the 'post' class. Here is what I have so far:
https://docs.google.com/document/d/1eI3rWD6ZmDPGDkUfWlng0ScK1SoqI5HLU0-Mn-GJXgI/edit
There are still so many features and ideas to reconcile. I must have changed the basic plan of the class hierarchy at least four times over the course of the weekend. The class "post" will still be the backbone of most aspects of the website, but as for how everything else relates to it is still up in the air.

What I'm searching for in all of this some means to tie everything together in a logical foundation that will help us avoid inefficient kludges later down the road. If the post class must change to accommodate all the other features then so be it, but I really want everypony's help.

Please comment, submit your own ideas, etc. -- the goal here being to plan out back-end logic and mechanics without actually writing them (which would result in wasted effort as plans are changed and reworked). Pseudo-code is really easy to rewrite as opposed to code. We can fill in the fine details of frontend (i.e. AJAX and whatnot) later.
>> No. 34742
I'd like to propose, for rewarding reviewers, putting good stuff in the spotlight and ensuring fairness, a very, very simple solution:

A star rating, but it must be accompanied by a feedback/review post. If the feedback is little more than a sentence, it'll be obvious the purpose is star-bombing, and it could be reported / its rating revoked while keeping the post.

I'm still a little on the fence about letting non-registered posters create projects. However, it could work, if tripcode, email and password were required for creating one. Authors (who have the password) could then, using the password to identify themselves, be able to offer reciprocal criticism.

The main thing that is missing from this system is automatic weighting of a person's rating of something else based on their history. That is another layer of complication we shouldn't have to deal with. As long as people who give ratings are compelled to accompany them each with an up-front review, they'll hopefully think more carefully. They cannot rate/vote anonymously (but must accompany a rating with an explanation of the rating) and so thus are easily held accountable by others who can see their reasons (or lack thereof) for their rating.

Everypony, your thoughts please?
>> No. 34743
File 133031910469.png - (842.64KB , 1600x1600 , 118459 - Alicorn artist equestria-prevails celestia derpy_hooves filly.png )
34743
>>34742
>A star rating, but it must be accompanied by a feedback/review post.
I'm a little iffy on stars ever since FimFiction abandoned it, but that's a minor detail. The feedback section sounds good. We could even set a 20-50 char minimum size.

Stuff like stars and karma, we could always take a straw poll in /fic/ to see what they'd like (or rather, propose a system and ask "does this sound good?")

>However, it could work, if tripcode, email and password were required for creating one.
Those pieces of info would be sufficient to create a registered account with *shrug*

>The main thing that is missing from this system is automatic weighting of a person's rating of something else based on their history... As long as people who give ratings are compelled to accompany them each with an up-front review, they'll hopefully think more carefully.
Sounds good.

Will take a look at the post diagram shortly.
>> No. 34788
File 133041108967.png - (70.15KB , 340x360 , how\'s that lack of oxygen feel?.png )
34788
I, as a parasprite, would like to be able to be able to practice my art with impunity.
I, as a user, would like to be able to change the color of the individual letters in whatever name I choose. For example, alternating orange and black for halloween, or yellow, red, and black for holocaust remembrance day.
I, as a poster, would like to express my (perhaps disturbing) lack of faith in both this project as a whole, and in the people tasked with executing it.

Now go choke on a balloon.
>> No. 34796
File 133041726993.gif - (315.42KB , 500x373 , 132979191794.gif )
34796
>>34788
>> No. 34841
>>34796
Well that's no fun.
>> No. 35049
Is this dead?
>> No. 35055
>>35049
No.
>> No. 35056
>>35049
Please don't bump unless you have ideas to add. You can also comment on the ideas doc (http://bit.ly/wD2Gu2)

Long story short, there's still a lot of planning, my day job is keeping me pretty busy, and taxes are coming up real soon, so this may go rather slowly. I have, however, still been doing research on what is and isn't possible, little by little, so that we can make informed choices on how to best structure it. The goal in planning is to avoid having to rely on inefficient kludges further down the road. I want to have a plan for the core models set in stone before proceeding because if we have to restructure everything later, it'll be wasted effort (not to mention more confusing).

>>35055
Roger, I don't believe I've thanked you enough for the thought and input you've given this project so far.
>> No. 35073
File 133093638138.jpg - (40.42KB , 361x550 , Gene-Wilder57259.jpg )
35073
>>35056
No thanks needed, really. I should thank you for the opportunity. When we get into the thick of things I'll probably be asking you to double-check half everything I'm doing. And I've been needing some sort of programming project to jump onto.

>posting Gene because I didn't make this folder for nothing
>> No. 36135
File 133299354138.png - (9.32KB , 593x285 , 132920562689.png )
36135
Pardon me for not sharing earlier, but in order to make our goals more concrete and help us further brainstorm, I've begun some detailed wireframing (the collection of wireframes is here: http://bit.ly/GWKol1) and when I'm done with that (it's not even half done yet) I'll do my best to compose a concise functional outline (which will be a blend of ideas from wireframing, feedback in this thread and the now practically defunct information architecture outline). From that and the wireframes, I and anypony who wishes to help should have some very solid, tangible goals to work from. It's still a good time to make suggestions / pose ideas...

The basic idea of the app (on the publishing, discussion and exchange side) is a trifecta of online discussion formats: one that is somewhat akin to an image board but with various enhancements (I mapped this out recently in the wireframes); one that is a queue-like system akin to Stack Exchange's, for requesting reviews/constructive criticism that can be filtered by responses, tags, etc.; one that is a story archive similar to FiMFiction, but with possible improvements. Underneath all three of these (as well as the private messaging part of the code) will be a single class, post. The goal in reusing this class in everything is to avoid repetition in coding. Post objects will each have all of the data necessary to render them already embedded in them, eliminating the need for relational database queries (and making it scale way better). Above them, in a one-to-many relationship with them, are threads and thread-like objects (thread subclasses), which include discussion threads, request "threads", story "threads" and private message "threads" (those latter three of which both have some features specific to them).

Now, as for me: my job, taxes, and other obligations have me reeling. I have been finding myself with a lot less energy and time in the evenings. Thus, I haven't been doing much work on this, and won't be able to for another week or so until I have one or more less things kicking me in the nuts. So, this project is temporarily on the far back burner as far as I'm concerned, but don't let that stop you from pointing out where I might be going about this wrong, or how it could be improved feature-wise.
>> No. 38935
File 133819847446.jpg - (96.28KB , 894x894 , 133040167465.jpg )
38935
https://[email protected]/Deconstrained/Gummii.git
Well, a few months later, I've finally done some actual development work in this framework and I've decided that I've been going about it all wrong. By this, I mean that the approach of "let's plan everything out carefully" is flawed insofar as none of us (save for the extremely seasoned veteran developers, or the developers of the framework itself, of which there are none among us) have the know-how to perfectly well-plan. Granted, it's best to have an idea of what you intend to do before doing it, but there's foresight and there's just over-planning. It's time to get this party started.

So what have I done? In the past eight hours, I have taken a decent user module (http://www.yiiframework.com/extension/yii-user), stripped it down, integrated it into an extension of the base web app, and vastly condensed/simplified/improved the boring, boilerplate user management stuff (which can be extended and improved upon later) so that we have a nice clean webapp (with less readymade bloat) to work with, not to mention having some enhancements (via extension of the CWebUser class) and RBAC (role-based access control), which will be instrumental in setting up the whole permissions and user management stuff later. I'm also working on a set of conventions (and hard rules) I'd like everypony intending on contributing to this project to follow, to make collaboration go more smoothly. Granted, there's still a lot of testing and debugging that must be done before it's remotely ready for extension, but it's damn near ready for building, because I've gotten the bare essentials for a multi-user, multi-role web app set up.

As for what comes next, after user management is totally clean and functioning well: I'm thinking we extend the database schema only as far as necessary to add new features, taking it one step at a time. First on the list (after the basic post table) is planning/building the controller(s) for a functioning multi-category web forum -- in addition to asynchronous HTTP awesomeness, like being able to see a quoted post by hovering over its link on a completely different page (something that FiMFiction can't do yet, but that's trivial to do in Yii with an AJAX call and a controller action that renders a post body). Then, the important parts of the app: projects, requests, personal messaging, a reporting system, subscriptions (to threads, projects, requests, users, etc) image uploading/linking, markup generation (i.e. from parsed BBCode), and security tightening.

Two conventions I would like to adhere to in this, that I probably haven't mentioned (and that aren't in the wireframes or brainstorming docs yet:
1. Only the high-profile security/info settings, i.e. password, role, date last visited and other really basic authentication type information goes in the user table. Everything else will go in a user_profiles or user_settings table. Well, we can have some wiggle room in this regard. But let's not mess with User too much, because it's essential to the functioning of the webapp.
2. As much as possible, let's re-use models and tables, in particular, the "posts" model/table. This shall remain (as in my original plans) the basic unit of communication. It needs some re-thought, but its role as the omnibus communication storage unit remains. With less relational junk that can result from using different tables for different types of messages, the mega-table can be indexed and later sharded across multiple databases for performance's sake, so we don't have to worry too much about performance until much later down the line.
>> No. 39195
File 133875453569.png - (79.71KB , 717x489 , Gummii-ERD-6-3-2012.png )
39195
Okay, lemme just make a confession first:

When I started planning this thing out, I hardly knew jack shit about relational databases or data modeling. I only had the faintest idea. So, last night (and the better half of this morning) I built up a database using InnoDB with foreign key constraint and indexes and whatnot that will actually work, and not fail horribly in terms of performance and data integrity.

The short of this update is that I'm going back to the idea of using posts to represent pretty much everything. It makes relations much simpler and easier to manage. Additional functionality and distinction between types will be performed by use of a 2-character "type" column. This will allow us to re-use the same back-end utilities for managing higher-level stuff like forum categories, while distinguishing in the RBAC and frontend how to treat each object. It also makes sharding in the future more feasible, because there are fewer tables to fuss with. Simple is beautiful.

With that said, I'd like to ask for a bit more patience while I get us some hosting for group testing (I'm a bit broke right now), but more importantly, a formal draft of the collaboration conventions (so that working together doesn't get confusing and time-intensive when/if new people come onboard) as well as a persistent channel on canternet.org for weekly meetings. Skype might be useful and fun too.
>> No. 39258
File 133881854511.png - (90.60KB , 1000x1000 , 131878542243.png )
39258
>>39195
>With that said, I'd like to ask for a bit more patience while I get us some hosting for group testing (I'm a bit broke right now)
We could use mine, so long as it's just between the devs. I dunno if paying for proper hosting is worth it for alpha stages.
>A persistent channel on canternet.org for weekly meetings. Skype might be useful and fun too.
Heeheehee. Skype might be fun. If we are to have a designated medium of communication, I would suggest sticking to just one. Schlocking between IRC and Skype and Google Chat will just get confusing, I think.

Anyway, I registered #gummii on canternet in case we want to use it.

Don't feel rushed or whatever, though. I've got so plenty of other stuff I need to do right now (non-inclusive list: write-off organising/peddling, that mechanics guide, four pending stories), so it's not like you're making me wait around or anything.
>> No. 39341
File 133895230799.jpg - (35.07KB , 730x714 , 131294797744.jpg )
39341
>>39258
Ditto (also, I have a domain name). The point of procuring third-party webhosting is mainly one of performance; even the cheapest hosting providers are likely to have a far faster connection than any of us, and security matters (though I'm no stranger to them) would make it more a hassle.
> Anyway, I registered #gummii on canternet in case we want to use it.
> mfw I forgot to tell you about #gummii-dev, which I registered this past weekend and have been lurking in ever since
>> No. 39778
File 134000111014.jpg - (163.54KB , 1280x1024 , 40211 - artist easteu gummy poison_joke.jpg )
39778
Whoa, Sunday 11:30 PM, where did my weekend go? Oh well. Anyhoof, I feel like I should at least post what I've done here so that it doesn't appear that I've abandoned this project (because much to the contrary, I just sunk many hours into it). I've made major inroads into an installer and theming method, built using the framework itself (so we can have input validation and whatnot).
- Wrote installation file template method (the installer will create files based on templates/installation variables and replace them).
- Basic main layout file using html5boilerplate (also, added html5boilerplate's htaccess directives, and some css/js)
- Integrated Zurb's "Foundation" CSS framework for some layout control & prototyping, removed the things that conflict with jQuery UI
- Just for kicks (and practice) developed an autocomplete widget for timezone selection that uses PHP's DateTimeZone class to acquire zones
- Script registry mapping to use theme-dependent CSS and JS instead of the system defaults (so, when constructing jui widgets, it'll use the currently active theme)
What it looks like (hideous):
http://youtu.be/2uN6uqWYWlo
What it is (still a bit messy, and you'll notice some unprofessional commit messages...):
https://github.com/Deconstrained/Gummii

It's been fun but exhausting. Still though, there's a lot that remains to be done before I start begging for help and publicizing it more, such as finishing the installer, creating some sample data to develop with, and getting the boilerplate models, views and controllers set up.

> my face when I'm running out of Gummy images
>> No. 40136
File 134068127120.jpg - (67.26KB , 512x943 , omg-it-spins.jpg )
40136
>>39778
> saging because I haven't done any QA on this commit... at all
https://github.com/Deconstrained/Gummii/commits/master
Hokay, gonna make this short. I spent the better half most of the weekend nerdgasming over developing a generalized "loading" overlay function with a theme-dependent image (that spins), which can be used to signify that part of the page is loading.
http://dl.dropbox.com/u/57284761/out-5-1.ogv
Oh, that's after I developed a neat event listener for intra-site links that reloads the main content with the new page (retrieved by AJAX). The great thing is that it's all implemented client-side, so if Javascript were disabled, it would all work just the same. Yii has a convenient way of checking if the request is an AJAX one, and I wrote an override of the render() method CActiveRecord in my extension to render partial if it's AJAX (to load new content in div#content) or render, if it's a request for the whole thing.

Anyhoof, the installer works. Barely. I'll hopefully get some basic testing data and CRUD code done by some time this next weekend. Then I'm off to vacation for a week starting July 6th. Please bear with me, I'll have the foundational work for this awesome new forum software done soon enough.
>> No. 43357
Doof a boof. I guess this thing never really got off the ground. Such a shame...
>> No. 45434
I really hope there's still some fire in the hearts of the people working on this.

I have an idea. However, I'm a toddler at web development, so the amount of learning it would take me to put this together would take either way too long or forever. But I still really like my idea.

A while back I became mildly interested in fanfiction, and I noticed some authors were writing fanfiction within the continuity of another writer's works. And some fanfiction writers were writing adaptations of Firefly's Adventure. And some fanfiction writers weren't doing fanfiction at all, and were writing a 100% original cast.

I was very interested in rounding up all the fiction I could and forming a relationship web between them, dividing each work up into chapters, comparing groups of works of two or more and seeing the compatibility, so that a giant metaphorical web would form, and you could gather large clusters of fiction into a single continuity.

When I read this thread, I was excited to read that the database-driven structure of this project perfectly accomodates this wish should the feature be implemented. I have no idea how difficult that would be, since I've never programmed with databases before, but the phrase "relational database", if it means what I think it means, brings my hopes up.

I'm also getting heavy vibes (probably an inferrence) that this was already a planned feature, or maybe even a given, from what I've read in this thread. IMO, it's a great step in the direction of collaborative writing, and it makes the nature of fictional settings on the site almost wiki-like.
>> No. 45438
>>45434
Are you talking about parent-child relationships between stories? That wouldn't be very hard to do with some tags (I. E: Parent:30493, where 30493 is the I.D of the parent story)
>> No. 45441
>>45438
I don't think so. That could simply things, but I'm afraid it might force the implication that one work is a spinoff of another. I think from a user standpoint, both writer and reader, it might be best if all works chapters are connected by default and a tag is set for the purpose of severing ties. I think in a wiki-like system this would be the most impartial way to handle chapter relationships -- it should help eliminate using a relationship system as a social circle tool, and it would deal with direct, clear incongruities between chapters.

I pick chapters because this seems to be the smallest unit of a story, and because of things like "alternate endings" being stored as chapters in the backend in most instances of them I've seen.

I just had the idea that an association/disassociation voting system could be made, but I feel like that could end up as a social circle tool as well.
>> No. 45442
>>45441
So you're saying that, instead of the relationship being defined by stories, they're defined by chapters?
>> No. 45450
>>45442
Preferably. A chapter is a nicely contained unit, almost like an episode of a TV show IMO. If a long, multi-chapter story has a detail that contradicts something in another story, they become utterly incompatible unless you divvy the work up into chapters.
>> No. 45639
>>45450
Okay, how's about this; The stories are still organized by stories, but you can still branch your own version off of an individual chapter.
Like when you're setting up a new story it gives you the option of selecting the parent story, and then selecting the last chapter to precede the new story.
Thataway, you can either 'read from series beginning' or 'read from story beginning' without having to bother with finding the next story.
(Also you can disallow branching from your story)

Sorry for the messy writing, am on phone...
>> No. 45707
>>45639
Perhaps. Considering the idea of a web of compatible but otherwise unrelated stories I don't really like the idea of parent stories from a structural standpoint, but this might be the best way to do a story with multiple endings.
>> No. 45721
>>45707
Yeah, I was just looking at the ease of implementation. If you have all the chapters separated you'd have to figure out how to navigate the chapters efficiently.
(You wouldn't want to have a link to 20 different chapters that all come after the current one, it'd be a structural nightmare!)

You would have to figure out which 'Story line' to stick to from beginning to end. And that could be hard to coordinate and setup!

Last edited at Tue, Sep 10th, 2013 00:48

[Return] [Entire Thread] [Last 50 posts]


Delete post []
Password    
Report post
Reason