Thread: NEW GUI FOR ALL BULBAPEDIA USERPAGES, USERTAG PAGES, AND COLOR TEMPLATE PAGES!

TRUE STORY: A few weeks ago, in school coincidentally, I was using up some of my down time editing some things on my YouTube Channel. At the same time, I was thinking about Bulbapedia for some reason and then it hit me: Bulbapedia needs a new GUI DESPERATELY! So my idea was this: On Usertag pages and color template pages, there will be a new “Add to userpage” button if it is not already there. If it is, it would be replaced with a “Remove from userpage” button, which would automatically enable an editing session on the user's userpage. On the userpage during an editing session, users would have the ability to move usertags around by clicking and dragging them to where they want them to be. They would also have the ability to modify their text, font(s), font size(s), font color(s), font style(s), background color(s), outline color, shape, and the picture displayed in the usertag. This feature would be accessed via a wrench icon that appears next to the usertag on mouse-over. To edit color templates, instead of having to enter the correct color code, a color palette similar to the one in Microsoft Paint would appear. All of these customizations would be made via a window that would appear when an edit is being made to the area.

Advantages/Disadvantages: This would remove all of the confusion caused by the complicated wikicode that the new GUI runs over, similar to how Windows Explorer runs over MS-DOS. This would make editing a userpage much simpler and more fun, as well as much quicker. On the other hand, a new GUI might bog down the new Bulbapedia servers, but look at the bright side: If it does work out in the end, it would be a great way to test their limits! Also, users that have been used to typing in the wikicode will inevitably have to adapt to the new GUI, whether they like it or not. To solve this, I thought of a "GUI Settings" section in the "Preferences" area, which would let users choose whether they wanted to use the new GUI or the old one.

Since I am not a web developer myself in any way, shape, or forme, I'd need all the help I could get from EXPERT web developers to help design this, if I can get enough people on Bulbapedia to agree on a new GUI, although since this is MY idea, I'd be the one who would call the shots of the new GUI Design Project, with a second-in-command appearing later on, after everyone that wants to help out the cause has joined the Project. This project would keep Bulbapedia and its GUI "moving with the times" and more popular on the Internet. So I need YOUR opinion: Is this a good idea or not, and why do you think the way you do? Also, do you think this would work, run, and function properly after most of the designing is done, and why do you think so or not? You don't have to answer if you don't want to, but I highly recommend it. You know, just so that I can get some feedback and input from others. If you do choose to respond to this, put your answer to the first question, your answer to the second question, or your answers to both questions in your comment. Thanks!
~N Studios 2012

I don't believe we have anyone that proficient in web programming on board who could implement that. Ready WYSIWYG editors for web exist but they implement stuff for text, not for complex structures, and your idea would require a highly expanded and specialised one.

Also, the last Windows that ran on MS-DOS was Windows ME. :p

Actaully, your statement about MS-DOS is incorrect. ALL Windows Operating Systems, even Windows 7, run on MS-DOS. It's just that Windows Explorer runs over MS-DOS and provides the GUI part of the OS. MS-DOS provides the OS with all of the functions and programs. If you use Command Prompt on a Windows OS-based computer, you'll be using MS-DOS, because Command Prompt is like a portal through Windows Explorer into MS-DOS. Anyway, thanks for your concerns and send anyone who you think may be able to help with this project to me, because I am REALLY devoted to this (on account of the fact that I can't understnad much of ANYTHING about wikicode, no matter how many times I read over "How to use Wikicode" kind of stuff)! Thanks anyway!
~N Studios 2012

Remeber user pages aren't like profiles that would be on the forums. It's for information really, not socializing.

Originally Posted by Pikachu9000

Actaully, your statement about MS-DOS is incorrect. ALL Windows Operating Systems, even Windows 7, run on MS-DOS. It's just that Windows Explorer runs over MS-DOS and provides the GUI part of the OS. MS-DOS provides the OS with all of the functions and programs. If you use Command Prompt on a Windows OS-based computer, you'll be using MS-DOS, because Command Prompt is like a portal through Windows Explorer into MS-DOS. Anyway, thanks for your concerns and send anyone who you think may be able to help with this project to me, because I am REALLY devoted to this (on account of the fact that I can't understnad much of ANYTHING about wikicode, no matter how many times I read over "How to use Wikicode" kind of stuff)! Thanks anyway!
~N Studios 2012

Do your research, I'm absolutely sure I am correct in this regard. Text mode does not equal MS-DOS; Windows 1.x, 2.x, 3.x, 95, 98 and Me were built on MS-DOS, while Windows NT series has never used MS-DOS. Go read about it. (that's four links)
(My claim was factually a bit off too, Windows 98 was the last system with fully working MS-DOS, the one in Me had real mode stripped away.)

Anyway, offtopic.

Also worth noting that calling this a GUI is technically incorrect; a GUI is the skin to a program, not the UI of a website.

But anyway. I'd like a better defense of the effort behind this. If Wikipedia doesn't do something like this -- and let's face it, Wikicode is substantially easier than just about any other content-editing language to learn the basics of -- why should we put the resources in it? Userpages are a tangential aspect of the Wiki. Would this improve the core editing of the wiki? I don't really want to pour any resources into improving the creation of userpages. They're fine as it is, and again, tangential to the overall user experience.

Whoa. You used lots of big words. Anyway, my idea behind this was to make it so that editing talk pages and mainspace articles would be left as wikicode, while the Userspace pages and the other types of pages I listed would use the new User Interface: One that enables users to click, drag, and modify templates, tags, and colors on their own userpages. This would make the life of someone who knows absolutely nothing about wikicode much easier because they wouldn't need to waste 12 hours learning how to use it right: they would just get on their userpage and take it from there. Heck, they could even make one from scratch instead of needing to use someone else's layout as a reference, which would bring more creativity to the world, which I believe is actually something it needs most. As well as this, editing userpages would take much less time, ensuring that more users get back to editing the mainspace faster, thus contributing to the wiki more. (That is, unless an edit war breaks out, but that's a different story.) Also, like I said in the original post, "To solve this, I thought of a "GUI Settings" section in the "Preferences" area, which would let users choose whether they wanted to use the new GUI or the old one." And even though you said that userpages are "a tangential aspect of the wiki," face it: easier-to-edit userpages=faster completion of userpages=more time spent making constrctive edits the mainspace. And I just thought of what the new interface would run on: JavaScript. It's what YouTube uses, and its new channel layout is what inspired me in the first place, it's relatively easy to program, and it's infinitely variable. When I say "infinitely variable," I mean that it allows for an infinite number of coding combinations, and those are what make up a website's key components, much like the support beams in a skyscraper. Since I don't even know how to access JavaScript editing, I'm pretty much useless in making it all on my own, which is why I asked for expert web designers for help on this. That is, if this project is given the green light, which now is looking a little bit doubtful for me, judging by the fact that I have many things going on in my life outside of Bulbapedia, such as schoolwork, projects that I'm making, videos that I'm making to be uploaded onto YouTube, that kinda stuff. Anyway, thanks for your input! I really appreciate it! (No sarcasm intended) Have a nice day!

~ N Studios 2012

Taking the time to learn more complex wikicode is not time wasted. Considering the userspace policy, the learning of more advanced wikicode through personal means offers the user more opportunities in which they may be able to assist in the content areas of Bulbapedia. This may then allow the user to continue editing their personal user page(s), without violating the policy and getting into trouble.

While making userspace edits easier may allow people more time for editing the mainspace, it also disallows users to gain a better understanding of wikicode by diving right into trying to make something fancy. Which is the better reward? A faster system that teaches nothing, while allowing more free time in the beginning. Or a system that may take some time, but also works as a wikicode learning experience?

@Pikachu9000 -- do you have any idea of the effort this would take in terms of man-hours of coding? I don't, so I'd appreciate some input on your end as to a rough estimate.

I'd say, nonstop, about 50-75, but that's just a guess. I'm also basing that guess off of the abilities of a master JavaScript developer. For a JavaScript n00b, like me (I don't even know how to enable JS), I'd be guessing in at around 100-200 hours nonstop. But that's if all focus is dedicated to it until it's completed. If focus is moved from one thing to another, it could take an endless amount of time. Literally. But after it's perfected for a sample of a userpage, usertag page, and color template page, it's just as simple as copying and pasting the script to all other pages like it!* But judging by how many pages there are on Bulbapedia, that could take some time. Hope this helps!

* = I'm just guessing, because I have no idea how to do anything with JavaScript. I seriously suck at coding and scripting and whatnot.

~ N Studios 2012

Originally Posted by Kogoro

Taking the time to learn more complex wikicode is not time wasted. Considering the userspace policy, the learning of more advanced wikicode through personal means offers the user more opportunities in which they may be able to assist in the content areas of Bulbapedia. This may then allow the user to continue editing their personal user page(s), without violating the policy and getting into trouble.

While making userspace edits easier may allow people more time for editing the mainspace, it also disallows users to gain a better understanding of wikicode by diving right into trying to make something fancy. Which is the better reward? A faster system that teaches nothing, while allowing more free time in the beginning. Or a system that may take some time, but also works as a wikicode learning experience?

I see your point, which is why I came up with a failsafe for the users who want to continue using wikicode. It was in my original post, so I think you may have missed it. Here's what it said.

Originally Posted by N_Studios

...users that have been used to typing in the wikicode will inevitably have to adapt to the new GUI, whether they like it or not. To solve this, I thought of a "GUI Settings" section in the "Preferences" area, which would let users choose whether they wanted to use the new GUI or the old one.

See? With that, users that want to learn more about how to use wikicode in the user namespace would still be able to. Also, this new interface wouldn't even apply to all of Bulbapedia, just the user namespace and template pages. So either way, everyone would still be using wikicode in the end. That, or they could go to Wikipedia and use the wikicode there, because I doubt the majority of the people who contribute to the World's Largest Community-Driven Online Encyclopedia would like my idea very much. But all in all, if this new interface was to be implemented on the wiki and at one point became 100% flawless and had no problems whatsoever (exaggeration there), everyone on Bulbapedia would have to keep using wikicode in order to use the new interface for the user namespace, because as we all know, in order to make edits to the user namespace, one must make edits to the mainspace first, and like I said before, the new interface wouldn't become a part of the mainspace, so all users would have to use wikicode at some point or another! Hope this helps!

~ N Studios 2012

@N_Studios; We do not have someone to put 2.5 man-weeks of work to a project like this. And if we did, we have many bigger projects to tackle. This is the kind of thing that I think the Wikimedia foundation would absolutely have tried handling if they believed it was feasible. I really think that the amount of coding required to make this work well (ie, not get blown up with the first upgrade of the software) is probably three times your high-end estimate or more, the more I think about it. And on the Bulba side I know the resources just aren't there.

I think it's really great that you're so passionate about something you've learned about in school. But part of learning something is then learning how to apply it in a way that is not just meaningful -- and this meets that standard -- but also feasible. There are plenty of things that, given infinite time and resources, would be super-awesome tech innovations. If we could make our own BBS software that was better than vB, you can bet we would! And it wouldn't take me all that much time to draw up a spec to create a better forum layout. But we don't have the time or the money it would take to rebuild our BBS in our image. So we're stuck with what we have, plus a bunch of add-ons, only one or two of which we did ourselves.

A major constraint in small tech organizations is resources. The technology is there to do things like this. But the resources just aren't. And if they were, I'd allocate them to projects which benefit the core mission of the site more than this would; I think even you acknowledge that this is tangential to what we do. I'd encourage you to take this to the Wikimedia foundation, especially when you've learned enough to be able to contribute to it in a meaningful way. But keep it up! You've got good ideas.