CMS Design - Project maPle

Printable View

Show 100 post(s) from this thread on one page

01-03-20
Snopboy

Re: CMS Design - Project maPle

Quote:

Originally Posted by SharpAceX

Just some thoughts I had.

1) Subjective but that design looks wildly outdated for 2020, complete with those reflections and glossy interface. If you're going to re-write everything, it makes sense to also just update the design so it doesn't look a decade old.
2) Nesting CSS styles 6 levels deep (.status.online .status-online .inner .fill, for example) is terrible for browser performance, not to mention code readability. There's also no need to be that specific when the markup here should be relatively simple.
3) Not sure why everything (at least just going off of that one screenshot of your CSS) is positioned absolutely. That's going to make supporting mobile extremely difficult, if that's even a factor for a Maple CMS.
4) You're much better off dropping a dated technology like jQuery in favor of just vanilla JS. Really you should be using a front-end framework like React or Vue for this but if you're going the plain JS route, then do that, jQuery is the worst option out of the 3 choices.

Good luck on this project.

Hi, will answer respectively.

1) I really liked the design itself, and honestly if you've seen my previous works (Maple designs and websites) you'd know how much of a fan I am, of the old styles, and I'm definitely not talking about the bland-ish old school designs, I'm talking about the good ones, unique, that stands out. I'm not one to go with Trends, imho making Hipster-ish "modern" designs for MS websites is a total meh, but oh well that's just my own taste and preferences.

2) As much as I don't like calling out, you're pretty wrong here. First of all, nesting CSS has zero impact on performance, literally zero. If by any chance it was done on a repetitive massive level (i.e. 10 levels or more, 20-30 times in the DOM or more, at the very least), then you might see a small performance loss in the browser (assuming you're on a PC and not Mobile).
The example given is only 3 levels deep, not counting the parent class of course. Mind you, this is LESS, not traditional CSS. LESS emphasizes code readability and maintainability, not superior performance over pure CSS (which is currently not possible, obviously) and btw it transforms into pure CSS after "compilation" (if you can even regard LESS->CSS as a compilation). I never go beyond 4 levels deep, it becomes unreadable and overall annoying.

3) Most of the elements are either set as relative, or default (as in, not set at all). The example given in the screenshots is of the Status widget, where the colored Bar is supposed to fill the inside of the container, as per the percentage set in the height, which makes total sense in this particular case. Overall I refrain from setting elements as Absolutely-positioned, it's a bad practice mostly, unless a use-case such as the Status widget is presented, where there's no better/preferred way of doing it.
As far as Mobile support goes, this specific theme will not be modified to be compatible with Mobile device, instead - a separate responsive theme will be presented to Mobile users by default. This will eliminate the need of making every single theme compatible with mobile devices, especially when most themes that will be released with this CMS will be as Old-School as could be, therefore absolutely incompatible with Mobile devices.

4) As mentioned previously, I really really REALLY hate JavaScript, in any and all forms. On-top of that I really don't see the point of pushing front-end frameworks in any Web App. It's good for certain cases, not all. I don't see the advantages it gives over not using a framework in this project. Now say I go with Vue, or React, or Angular (remember what happened with the first Angular..?), that would mean keeping it up-to-date with the framework itself, it would mean forcing everyone who wishes to use this CMS, to learn something they might not be interested in, also might deter them from using this CMS.
Don't forget - by going with a front-end framework, I'm basically turning a rather simplistic process of setting this CMS up, into a nightmare. Because then you wont only need LAMP(prod)/WAMP(dev) stack, you will also need NPM and more technologies and softwares, as well as dependencies to run. I might as well quit this project now instead LOL :P
Yes, jQuery is old, yes it doesn't have good rep in this day and age, but it gets the job done with minimal work. Especially when all I use it for is simple DOM manipulations and Animations, which isn't bad at all. Trust me when I say this, when the need arise to write actual front-end code (JS), I will definitely do it with pure JS over jQuery or any other third-party library. It's better that way.

Thanks for the input, and of course - wishing me good luck however, how about you join this project? I'm honestly hoping to see Community Effort in this open source project, once it becomes open source. :thumbup:

I honestly can't get my head around this, it's so annoying to see the MU community getting together to produce top-notch emulators and CMS, yet the MSPS community is just full of leechers and trolls who flame all day long. We are, as a community, too busy being toxic to one another, instead of helping each other out, and promoting the Game, as well as getting everyone to get better whether as Persons or Developers. It's sad to see most servers out there are still using 6yrs old CMS that was built the same way, with the same tech and practices as 15yrs old websites. At least there's some progress in the Emulators (Server Files) field, where there's nearly none in the Web.

P.S. If I'm seen as if my comment is insulting, misunderstood or anything, it is not my intention. I'm just tired af as a result of working a full time Physical job (10-12hrs a day). Also my free time is limited to weekends which is more annoying, not having the time to dedicate for this project on the daily-basis.
01-03-20
SharpAceX

Re: CMS Design - Project maPle

Quote:

Originally Posted by Snopboy

Hi, will answer respectively.

1) I really liked the design itself, and honestly if you've seen my previous works (Maple designs and websites) you'd know how much of a fan I am, of the old styles, and I'm definitely not talking about the bland-ish old school designs, I'm talking about the good ones, unique, that stands out. I'm not one to go with Trends, imho making Hipster-ish "modern" designs for MS websites is a total meh, but oh well that's just my own taste and preferences.

2) As much as I don't like calling out, you're pretty wrong here. First of all, nesting CSS has zero impact on performance, literally zero. If by any chance it was done on a repetitive massive level (i.e. 10 levels or more, 20-30 times in the DOM or more, at the very least), then you might see a small performance loss in the browser (assuming you're on a PC and not Mobile).
The example given is only 3 levels deep, not counting the parent class of course. Mind you, this is LESS, not traditional CSS. LESS emphasizes code readability and maintainability, not superior performance over pure CSS (which is currently not possible, obviously) and btw it transforms into pure CSS after "compilation" (if you can even regard LESS->CSS as a compilation). I never go beyond 4 levels deep, it becomes unreadable and overall annoying.

3) Most of the elements are either set as relative, or default (as in, not set at all). The example given in the screenshots is of the Status widget, where the colored Bar is supposed to fill the inside of the container, as per the percentage set in the height, which makes total sense in this particular case. Overall I refrain from setting elements as Absolutely-positioned, it's a bad practice mostly, unless a use-case such as the Status widget is presented, where there's no better/preferred way of doing it.
As far as Mobile support goes, this specific theme will not be modified to be compatible with Mobile device, instead - a separate responsive theme will be presented to Mobile users by default. This will eliminate the need of making every single theme compatible with mobile devices, especially when most themes that will be released with this CMS will be as Old-School as could be, therefore absolutely incompatible with Mobile devices.

4) As mentioned previously, I really really REALLY hate JavaScript, in any and all forms. On-top of that I really don't see the point of pushing front-end frameworks in any Web App. It's good for certain cases, not all. I don't see the advantages it gives over not using a framework in this project. Now say I go with Vue, or React, or Angular (remember what happened with the first Angular..?), that would mean keeping it up-to-date with the framework itself, it would mean forcing everyone who wishes to use this CMS, to learn something they might not be interested in, also might deter them from using this CMS.
Don't forget - by going with a front-end framework, I'm basically turning a rather simplistic process of setting this CMS up, into a nightmare. Because then you wont only need LAMP(prod)/WAMP(dev) stack, you will also need NPM and more technologies and softwares, as well as dependencies to run. I might as well quit this project now instead LOL :P
Yes, jQuery is old, yes it doesn't have good rep in this day and age, but it gets the job done with minimal work. Especially when all I use it for is simple DOM manipulations and Animations, which isn't bad at all. Trust me when I say this, when the need arise to write actual front-end code (JS), I will definitely do it with pure JS over jQuery or any other third-party library. It's better that way.

Thanks for the input, and of course - wishing me good luck however, how about you join this project? I'm honestly hoping to see Community Effort in this open source project, once it becomes open source. :thumbup:

I honestly can't get my head around this, it's so annoying to see the MU community getting together to produce top-notch emulators and CMS, yet the MSPS community is just full of leechers and trolls who flame all day long. We are, as a community, too busy being toxic to one another, instead of helping each other out, and promoting the Game, as well as getting everyone to get better whether as Persons or Developers. It's sad to see most servers out there are still using 6yrs old CMS that was built the same way, with the same tech and practices as 15yrs old websites. At least there's some progress in the Emulators (Server Files) field, where there's nearly none in the Web.

P.S. If I'm seen as if my comment is insulting, misunderstood or anything, it is not my intention. I'm just tired af as a result of working a full time Physical job (10-12hrs a day). Also my free time is limited to weekends which is more annoying, not having the time to dedicate for this project on the daily-basis.

1) Design is pretty subjective. I didn't call the design bad or ugly, simply that it is outdated. I think that's a fair claim to make when you consider that that style of design was definitely popular a decade ago. I'm only saying that calling this design modern in 2020 would be disingenuous at best.

2) I literally do this professionally, so I'd hope I know what I'm talking about here. Deeply nesting selectors like you did absolutely adversely affects performance, and saying "literally zero" makes this kind of humorous. Browsers are not magic. The example given is 4 full-blown levels deep, not 3, of course the parent selector counts, there's no such thing as "0th level deep CSS", not sure why you're disregarding the parent selector here. The parent selector is part of the chain of selectors that the browser must take into account when styling.

But if you don't want to take my word for it, then don't, here are some helpful and informative articles from industry professionals if you wish to learn:

"Avoid deeply nested Sass/preprocessor declarations. The expanded code can become unexpectedly large."
https://www.sitepoint.com/optimizing-css-performance/

"We've written before about the dangers of nesting your CSS selectors too deeply." (This is literally from the creators of a CSS preprocessor)
Avoid nested selectors for more modular CSS

"To avoid costly style calculations, reduce complex and deeply nested selectors so that it’s easier for the browser to figure out which element a selector is referring to."
https://www.hongkiat.com/blog/writing-better-css/

If you still want to deeply nest styles for some reason, then by all means, it's your project, but let's not spread misinformation about CSS because the performance impacts here are not "literally zero".

3) Maybe I didn't exactly follow what you meant by "making every single theme compatible with mobile devices", I thought there was only one theme here. Supporting mobile for any theme is fairly straightforward given you don't follow bad practices when building the desktop versions (using absolute improperly/excessively). I agree that mobile styles is likely not a priority but my impression here is that the point of this project is to take an old existing project and bring it up to date, using modern technologies and modern practices/standards. Serving up different themes (one for desktop and one for mobile) is an outdated practice back when phones were too weak to handle a more fleshed out version of the site. Nowadays you can safely serve up the same HTML+CSS to both desktop and mobile.

4) Because you're only using it for "simple DOM manipulations and animations" is pretty much the best argument ever to drop jQuery in this case: you're not actually using it for anything a modern browser doesn't already support natively. Only reasons to still use jQuery for the simple things you're using it for is if you want to support IE 11, or you're lazy and would rather just reuse old code instead of rewriting it without jQuery, which is fair enough.

There's no reason for me to join this project but I'll certainly browse through the code once it's open source, why not. You mentioned the MS community being full of leechers and you're absolutely correct. The moment this project gets any traction, you will get a dickhead who downloads it and the first thing they will do is wipe your credits from the footer or otherwise deprive you of your rightfully deserved credits.

For example, the highest ranked GTOP server I could spot doing this: https://maplelegends.com/ Looks like MapleBit to me (and anybody with eyes), and comparing the view-source markup to MapleBit on Github definitely reveals some identical class names and structure. "Heavily inspired" would put it lightly, if not, outright copy+pasted, yet I don't see any acknowledgement or credits whatsoever.

People are also doing the exact same with my CMS, Aria, which is why I purposely only open-sourced the front-end and actively sell the back-end instead to deter leechers, when I wanted instead to have the entire thing public for free. Basically what I'm saying here is expect to see your work to be ripped/copied by this community if your project gets far enough. I don't know anything about the MU community but I'd imagine that they're more respectful of other people's works which in turn encourages more people to contribute their own work.

In this community, you're incentivized to either sell your work or keep it private because if you make it public, people who are already making money will take your free work, remove your credits, then wonder why the community is dying as people refuse to let their own work get exploited by others. I still legitimately wish you luck on this project, perhaps somebody in the community might contribute with you but I wouldn't hold my breath on that. And yeah I didn't view your comment maliciously in any way and I hope you don't for mine as well.
04-03-20
Snopboy

Re: CMS Design - Project maPle

Quote:

Originally Posted by SharpAceX

1) Design is pretty subjective. I didn't call the design bad or ugly, simply that it is outdated. I think that's a fair claim to make when you consider that that style of design was definitely popular a decade ago. I'm only saying that calling this design modern in 2020 would be disingenuous at best.

2) I literally do this professionally, so I'd hope I know what I'm talking about here. Deeply nesting selectors like you did absolutely adversely affects performance, and saying "literally zero" makes this kind of humorous. Browsers are not magic. The example given is 4 full-blown levels deep, not 3, of course the parent selector counts, there's no such thing as "0th level deep CSS", not sure why you're disregarding the parent selector here. The parent selector is part of the chain of selectors that the browser must take into account when styling.

But if you don't want to take my word for it, then don't, here are some helpful and informative articles from industry professionals if you wish to learn:

"Avoid deeply nested Sass/preprocessor declarations. The expanded code can become unexpectedly large."
https://www.sitepoint.com/optimizing-css-performance/

"We've written before about the dangers of nesting your CSS selectors too deeply." (This is literally from the creators of a CSS preprocessor)
Avoid nested selectors for more modular CSS

"To avoid costly style calculations, reduce complex and deeply nested selectors so that it’s easier for the browser to figure out which element a selector is referring to."
https://www.hongkiat.com/blog/writing-better-css/

If you still want to deeply nest styles for some reason, then by all means, it's your project, but let's not spread misinformation about CSS because the performance impacts here are not "literally zero".

3) Maybe I didn't exactly follow what you meant by "making every single theme compatible with mobile devices", I thought there was only one theme here. Supporting mobile for any theme is fairly straightforward given you don't follow bad practices when building the desktop versions (using absolute improperly/excessively). I agree that mobile styles is likely not a priority but my impression here is that the point of this project is to take an old existing project and bring it up to date, using modern technologies and modern practices/standards. Serving up different themes (one for desktop and one for mobile) is an outdated practice back when phones were too weak to handle a more fleshed out version of the site. Nowadays you can safely serve up the same HTML+CSS to both desktop and mobile.

4) Because you're only using it for "simple DOM manipulations and animations" is pretty much the best argument ever to drop jQuery in this case: you're not actually using it for anything a modern browser doesn't already support natively. Only reasons to still use jQuery for the simple things you're using it for is if you want to support IE 11, or you're lazy and would rather just reuse old code instead of rewriting it without jQuery, which is fair enough.

There's no reason for me to join this project but I'll certainly browse through the code once it's open source, why not. You mentioned the MS community being full of leechers and you're absolutely correct. The moment this project gets any traction, you will get a dickhead who downloads it and the first thing they will do is wipe your credits from the footer or otherwise deprive you of your rightfully deserved credits.

For example, the highest ranked GTOP server I could spot doing this: https://maplelegends.com/ Looks like MapleBit to me (and anybody with eyes), and comparing the view-source markup to MapleBit on Github definitely reveals some identical class names and structure. "Heavily inspired" would put it lightly, if not, outright copy+pasted, yet I don't see any acknowledgement or credits whatsoever.

People are also doing the exact same with my CMS, Aria, which is why I purposely only open-sourced the front-end and actively sell the back-end instead to deter leechers, when I wanted instead to have the entire thing public for free. Basically what I'm saying here is expect to see your work to be ripped/copied by this community if your project gets far enough. I don't know anything about the MU community but I'd imagine that they're more respectful of other people's works which in turn encourages more people to contribute their own work.

In this community, you're incentivized to either sell your work or keep it private because if you make it public, people who are already making money will take your free work, remove your credits, then wonder why the community is dying as people refuse to let their own work get exploited by others. I still legitimately wish you luck on this project, perhaps somebody in the community might contribute with you but I wouldn't hold my breath on that. And yeah I didn't view your comment maliciously in any way and I hope you don't for mine as well.

1) I totally agree, though isn't that the beauty of it? :)

2 & 3) Again, as I said previously, it doesn't matter much because this site is still very small, there won't be any performance loss since it's not being done on a huge scale excessively. Moreover, don't forget that it's not 2005 anymore - the average PC is much more powerful than back then, and therefore the performance of the browser is much better. The only ones lacking in power are Mobile phones, which is why Modern mobile sites aren't heavy, even today, contrary to desktop sites. My point still stands.
I mean, this won't be a single-theme CMS, imho it shouldn't be. The objective here is to provide a public CMS where anyone who wishes to use it can very well do so without going through a complicated process of setting it up. If someone wishes to make changes to it (including making their own theme or using one that was released), they should have an easy way for it. Making themes for this CMS is as easy as simply reading and writing in English. If you know HTML & CSS it will do, no PHP will be needed (since mostly it's Laravel's Blade). Sure, this CMS will indeed be released with several styles, some of which will in fact come as "Mobile-ready", but not all. This option of whether to serve a distinct mobile site or have the regular site adjust itself for Mobile (responsiveness) should be left to the creator of each theme. This particular design would require quite a bit of modifications and redesigning certain elements within the PSD, well before coding it, which as I mentioned previously- will not be done. All I said in regards to the design is that it's lacking in content, a lot of elements and pages that are needed, are simply missing and therefore will be designed from scratch due to not having any other viable option.
What I meant about "bringing it up-to-date" was the community and servers, because they are mostly still using MapleBit, which is something that should obviously change for their sake. Sure MapleBit gets the job done alright but it's old and it's not as powerful, nor easy to work with (if you ever coded a theme for MapleBit, you'd know - it's a mess), this CMS is an MVC, therefore a complete separation between business logic and presentation, plus all of the Blade Engine advantages. :D

4) I'm being lazy indeed. I just don't wish to waste too much time on developing a front-end API for DOM manipulation at this point in time, it seems unneeded especially since jQuery does just that. No point in reinventing the wheel.

It seems like because I spoke of the MU community, it made you make assumptions as if I'm not from this community. I was just complaining about the state of our community and showing the MU community as a good example of a good community, I'm in no way a part of said community, it was just an example. And yes, I know this very well by now trust me, I've had a few releases in the past, and some had precisely this kind of attraction. This is how I got to making the base for MapleOrigin. At first they used my ExonicMS release (an old MapleBit with @Iranhik ExonicMS design), then they recolored it a little bit and removed the credits. In the end they were nice enough to restore the credits without much hassle which is when I decided to work on the CMS and share it with them first, before releasing it. Eventually due to communication issues with the Owner, I decided to not continue with them and instead turn this into an open source first, before having them (or any other server) test this and have the privilege of having it first.

I remember a long time ago I asked Kimberly about their site, apparently Navi coded the MapleLegends website back-end in Python, but the front-end is in fact a modified template of MapleBit.

Yeah, I'm aware of what you did with Aria and I remember you did mention sometime somewhere that someone did in fact remove your credits xD honestly that's to be expected given the current state of this community.

As for the last paragraph, let's push this change then :)

Sorry for the late reply, I did read your comment the same day it was posted but didn't have the time to write a reply :/
05-03-20
SharpAceX

Re: CMS Design - Project maPle

Quote:

Originally Posted by Snopboy

1) I totally agree, though isn't that the beauty of it? :)

2 & 3) Again, as I said previously, it doesn't matter much because this site is still very small, there won't be any performance loss since it's not being done on a huge scale excessively. Moreover, don't forget that it's not 2005 anymore - the average PC is much more powerful than back then, and therefore the performance of the browser is much better. The only ones lacking in power are Mobile phones, which is why Modern mobile sites aren't heavy, even today, contrary to desktop sites. My point still stands.
I mean, this won't be a single-theme CMS, imho it shouldn't be. The objective here is to provide a public CMS where anyone who wishes to use it can very well do so without going through a complicated process of setting it up. If someone wishes to make changes to it (including making their own theme or using one that was released), they should have an easy way for it. Making themes for this CMS is as easy as simply reading and writing in English. If you know HTML & CSS it will do, no PHP will be needed (since mostly it's Laravel's Blade). Sure, this CMS will indeed be released with several styles, some of which will in fact come as "Mobile-ready", but not all. This option of whether to serve a distinct mobile site or have the regular site adjust itself for Mobile (responsiveness) should be left to the creator of each theme. This particular design would require quite a bit of modifications and redesigning certain elements within the PSD, well before coding it, which as I mentioned previously- will not be done. All I said in regards to the design is that it's lacking in content, a lot of elements and pages that are needed, are simply missing and therefore will be designed from scratch due to not having any other viable option.
What I meant about "bringing it up-to-date" was the community and servers, because they are mostly still using MapleBit, which is something that should obviously change for their sake. Sure MapleBit gets the job done alright but it's old and it's not as powerful, nor easy to work with (if you ever coded a theme for MapleBit, you'd know - it's a mess), this CMS is an MVC, therefore a complete separation between business logic and presentation, plus all of the Blade Engine advantages. :D

4) I'm being lazy indeed. I just don't wish to waste too much time on developing a front-end API for DOM manipulation at this point in time, it seems unneeded especially since jQuery does just that. No point in reinventing the wheel.

It seems like because I spoke of the MU community, it made you make assumptions as if I'm not from this community. I was just complaining about the state of our community and showing the MU community as a good example of a good community, I'm in no way a part of said community, it was just an example. And yes, I know this very well by now trust me, I've had a few releases in the past, and some had precisely this kind of attraction. This is how I got to making the base for MapleOrigin. At first they used my ExonicMS release (an old MapleBit with @Iranhik ExonicMS design), then they recolored it a little bit and removed the credits. In the end they were nice enough to restore the credits without much hassle which is when I decided to work on the CMS and share it with them first, before releasing it. Eventually due to communication issues with the Owner, I decided to not continue with them and instead turn this into an open source first, before having them (or any other server) test this and have the privilege of having it first.

I remember a long time ago I asked Kimberly about their site, apparently Navi coded the MapleLegends website back-end in Python, but the front-end is in fact a modified template of MapleBit.

Yeah, I'm aware of what you did with Aria and I remember you did mention sometime somewhere that someone did in fact remove your credits xD honestly that's to be expected given the current state of this community.

As for the last paragraph, let's push this change then :)

Sorry for the late reply, I did read your comment the same day it was posted but didn't have the time to write a reply :/

1) Fair enough, to each their own.

2) I completely agree that hardware is more powerful today than ever before. My main point was instead that your style of writing CSS is not only not ideal from a readability standpoint (which is subjective), but it is definitely outright recommended to avoid this practice (which is objective). If my numerous articles did not persuade you to do it the recommended way, then that's fine, I'd rather not go in circles here, it's your project.

3) Easily supportable themes could be cool, but given no previous CMS has done this properly in the past, I'll just wait and see how you support themes with your CMS re-write.

4) Not quite sure what you mean by "developing a front-end API for DOM manipulation". It is literally natively supported. The API for DOM manipulation is already "developed" for you. jQuery, under the hood, is already using those exact functions that I'm suggesting you just use directly. For the tiny amounts of code you need, jQuery is offering zero benefit here except to save you the half hour it might take you to translate the code. For a project intended to be modern, taking half an hour to completely drop a dated technology like jQuery seems like a complete no-brainer to me.

If we as a community have collectively agreed that taking free work and simply modifying it means you now have the right to erase all credits from the original releaser, then yeah, good luck getting people to contribute with that mentality. People who release their work for free are already not getting paid for it, literally the only thing they're asking in return is to keep their credits intact, but not even that basic wish is respected.

As mentioned before, the moment this project becomes viable, people will begin to use it, remove your credits, and proceed to use it to help make hundreds/thousands of dollars. If you do not personally care about that at all, that's great, then you have nothing to lose, and you're the perfect person to lead this project. However, I think that real change is not going to be releasing another project and simply hoping that the same people change. You cannot normalize the act of removing credits and then expect people to want to contribute knowing their work will also suffer the same fate.

Show 100 post(s) from this thread on one page