1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Admin options/ mods/ bloat and understanding dev pov better

Discussion in 'XenForo Pre-Sales Questions' started by Shanj, Sep 20, 2010.

  1. Shanj

    Shanj Well-Known Member

    Following both the Suggestions forums, there is often heated dispute about whether or not to have X feature as an admincp option as core, or fully integrated.

    One way to approach this is via the moral or social issue.
    Some of us want feature X left well alone because they/ we don't see it as necessary.
    Some feel that it is fairer to add a feature X as an admincp option and leave it to us as admins to enable/ disable according to the needs of our boards as we see them.

    I very much belong to the second point of view. The major thing that got me choosing the forum software I did choose, years ago, was how many options it offered me that fitted my needs.
    I was also seduced by the lovely modding community.
    But I discovered that mods can be a pain over time because sometimes they just don't work; getting changes made as my board needs changed has been difficult or impossible - mods got too busy to help even if paid, or disappeared all together. (An honorable exception was Logician who hangs in there updating, and providing advice on adaptations way beyond the call of basic duty.)
    Upgrades can be a mess for a lot of people I understand.

    So the oft repeated cry "you can mod it" is not at all the ideal solution, at least not reliably.
    If you're a coder you can. If you're lucky and get a good coder for love or money, you can. But many of us can't, don't have enough time or energy from our many projects to learn, and can't find reliable coding support.

    So, back to the core, the integrated stuff.
    It would be helpful to understand a bit more what the pressures are about this. I'm beginning to understand that it's not so simple as just adding on things so admins can choose.
    People talk knowledgeably about "bloat." The concept is intuitively understandable to me, but only superficially.

    I thought it would be useful for me and quite a few others to open this up and educate us more on what "bloat" is about.
    Then we'd be able to be more mature clients, with a bit more judgement skill on when asking for X, Y and Z is less or more of a problem to actually do for the team.

    These might not be the way you'd approach the subject. But they illustrate the kind of mindset of a non-coder admin.

    ~ What kinds of functions are the worst criminals re "bloat"?
    ~ What kinds of functions are reasonable re "bloat"?
    ~ Are there other considerations where feature X actually cuts down on a mass of stuff - shortcuts it - so if it adds in another way there can be a net gain?

    Another way of putting it is
    ~ What kind of [Suggestions] are welcome as comfy to put in?
    ~ What kind of [Suggestions] are an unwelcome sight because they look simple to us non-coders but they mean headaches for the team? (or a modder)

    LATER: Then there's "plugins" which seem to be a halfway house between "core" and "mod."

    I just thought if we admins who are not coders could understand the developers point of view just a bit better we could be more considerate and not waste time with unworkable ideas.
    Of course some of this will be unpredictable - it depends on a lot of factors - kind of thing.
    But surely it should be possible to explore at least some outline guidance.
    Darkimmortal and Anthony Parsons like this.
  2. Brogan

    Brogan XenForo Moderator Staff Member

    I've posted this elsewhere several times concerning core features and add-ons.

    If it's an ACP option which, when disabled, removes all trace of it from the forum to regular users then it's only code bloat and I can't see why that would bother anyone.

    Yes it might take a few more bytes of hard drive space but it's not going to affect the operation or look of the forum.

    With regards to the default features/add-ons argument, I've said it before - one person's feature is another person's option.

    What some consider essential, others consider superfluous and irrelevant.

    You will never please all of the people when it comes to an out of the box product.
  3. Elizabeth

    Elizabeth Well-Known Member

    Let's put it this way:
    In the vb suite which I paid for, BLOAT is the blogs and the cms. I wish the cms wasn't bloat but I simply could not get it to work no matter how hard I tried. Yes, I can disable them but they are still there cluttering up my admin panel.
    That's BLOAT to me.
  4. Shanj

    Shanj Well-Known Member

    Yes I've seen various comments here and there but not a clear explanation in one place.
    Certainly not on a level that a noncoder could grasp.

    I thought that 'code bloat' is exactly what gets some members here frustrated and annoyed?
    I'd have thought that if disabling it removes it completely - a bit like not downloading part of a program so it isn't there from the start - surely then it's GONE so it ISN'T adding to load or 'bloat'?
    I understood 'bloat' to be something the script has to keep going through repeatedly every time standard things happen, only to get instructions (as a script) that all that stuff isn't necessary. So the bloat happens when disabling DOES NOT remove all that stuff.
    Which would make sense if the disable/ enable toggle is something the admin can switch back again later.

    No you can't please everyone. But the developers do have to make decisions and I doubt that's as random as throwing dice! So I'm asking for a little education on what their decisionmaking is like. Specifically so as to be more considerate, less timewasting on my end of it.
    After all if I know that certain kinds of stuff is very unlikely to fit within what the devs can reasonably do, then I can adjust to that in my planning AND not waste their time.
    As I said some of this is undoubtedly a big "it depends" too complex to explain to a noncoder/ too dependent on the state of the product at the time ... but some of the issues should surely be shareable.
  5. Shanj

    Shanj Well-Known Member

    Ah yes I understand THAT!
    I have already asked here and elsewhere to be able to create my own personalised menu on the front page of the admincp, giving links to the most frequently used areas I personally use.
    NOT done on auto either - some areas I don't visit often but when I do I want them at top level.
    So I want to compile a MY MENU manually.

    However is this what is generally meant by "bloat"?
    I thought there were bloat issues about impacty on server/ lots of unused code, some of it sometimes causing problems?
    And add-ons integration ....

    I really wanna learn!
  6. Brogan

    Brogan XenForo Moderator Staff Member

    From what I've seen so far, a lot of it is to do with feedback on this forum.
    The ability to add all sorts of rubbish to the postbit being a case in point.
  7. Anthony Parsons

    Anthony Parsons Well-Known Member

    A truly great system could even allow the removal of ACP options from view, ie. one panel that utilises usergroup permissions to view specifics, mod, super mod, admin, super admin. If a super admin can control who views what, even turn things off from their view... well... options away with zero bloat in the front or backend.
  8. Brogan

    Brogan XenForo Moderator Staff Member

    phpBB has what is called Module Management so you can tailor the ACP to exactly how you want it.
    I've never used it though, so some would call that bloat.
  9. Brandon_R

    Brandon_R Guest

    Even if the option removes from view, it is still running an if condition in the background and i think many gripe at that also. I think the best thing the developers can do is judge each suggestion logically and unbiassedly and determine if it fits well into their design principles and philosophies. xenForo isn't going to be for everyone.

    IB tried to make vbulletin for everyone and now no one wants it.

    Lets learn from their mistakes.
    Peggy likes this.
  10. Shanj

    Shanj Well-Known Member

    So when people talk about "bloat" we really need it to be made clear whether this is admincp clutter? or IF chunks of script hanging around?

    Admincp clutter could be easily handled by a manually selected personal menu.

    Can I have some more info on the IF condition problem?
    I mean doesn't a script jump if it has an IF = NO section - to the next IF?
    Or does it chug on through every line - which I can see adds 'bloat'? But in that case I thought scripts get read and acted on very fast?
  11. Brandon_R

    Brandon_R Guest

    They're pretty much the same thing. If you have bloat in the Admin CP usually there are blocks of code floating around to handle that bloat. The converse isn't necessarily true though.
  12. Dean

    Dean Well-Known Member

    To me: "bloat" is not just a 'will it be used' question, it is a 'how complicated is it to understand' question.

    Primarily for the usercp, but also in the admincp.

    examples of things that may be hard to understand could be complex alert notifications for the user cp. From what I have seen those in the usercp are easy to understand at this time.

    examples of things easy to understand might be being able to edit PCs for a short amount of time after they are submitted. The user looks at the message, sees a mistake, and the edit button, then fixes the mistake. But there will be admins that will disable that, if there is a simple box to edit the number of minutes for that feature to be available, and 'zero' disables it, that seems simple to me.
  13. Greg

    Greg Active Member

    I'm a big fan of the UNIX philosophy of 'Do one thing, and do it well'. A huge codebase quickly gets unweildy, as things get way too tied together. This is where the MVC system that XF takes advantage of comes into play. The system makes it really easy for modifications to be created, but more than that, it allows the heart of the forum software to stay small and clean and maintainable. Any extensions are their own entities and can be maintained seperately.

    If Kier and Mike were to make official mods, and even if they were packaged in the default install, what's the big deal if they not only can be disabled but actually removed?
    feldon30, grant sarver and Peggy like this.
  14. feldon30

    feldon30 Well-Known Member

    Considering the MVC design philosophy of XenForo, this definition could mean removing virtually every feature of XenForo.

    It always irked me that even if you had Profile Photos, or the Calendar, or the Photos features disabled in vB3.x, they still showed up in Usergroup Permissions, making the Usergroup Permissions a massive page to edit. I'd like to see a js toggle at the top "Show Hidden Options" or "Show Enabled Options".

    I really like the idea of having *included plugins*. What I mean is, package functionality with XenForo, but keep it in a plugin which is disabled by default. This way, your control panels and UI are clean and easy to navigate, but the software is not light on features.

    Menalto Gallery is a good example of this.

    The "full package" install of Menalto Gallery (a php photo gallery product) comes with about 40 plugins which are disabled by default. Here are just some:
    • Search Engine Friendly URLs
    • Reupload (to replace a photo without changing the URL)
    • Java Upload (to allow bulk uploads)
    • ImageMagick support for resizing images/thumbnails
    • Slideshow
    • JavaScript Slideshow
    • Adsense
    • FFMPEG support for videos
    • image blocks
    • album cover browser
    • contact us
    • shadowbox
    • share photo by email
    • latest albums
    • latest uploads
    • download full size
    • download archive
    • image tags
    • exif GPS
    • export to facebook
    • rss export
    • sitemap
    Now ask the top 25 site admins running big photography sites, and they will each tell you that some of the features above are Required (Core), some are Bloat, and some they're on the fence about.

    But since they're all plugins, they are only visible when you switch them on. Tons of functionality -- when you need it.

    This is why more and more software have Basic and Advanced modes. Photoshop just upped the ante and added like 10 different modes from Basic to Photography to Video to Animation to Advanced.
    Forsaken likes this.
  15. feldon30

    feldon30 Well-Known Member

    To say that the problems of vBulletin 4 boil down to feature bloat is to really mischaracterizes the situation and cloud this discussion. If vBulletin 4 had been vBulletin 3 with more features bolted on, then vB4 would not be so universally regarded as a poor upgrade.

    The issues were a poor quality style which is extremely difficult to customize, feature regression (loss of features over vB3), poor performance, and no real usability improvements over vB3. Most of the time spent customizing or using vB4 is trying to figure out how to do something you could easily do in vB3.

    So please don't just say that feature bloat is bad and point to vB4 as your shining example, because it's really not accurate. Honestly, vB4 doesn't really add many features that I can see.
    Forsaken likes this.
  16. Brandon_R

    Brandon_R Guest

    The problems of vBulletin 4 boils down to poor coding and an invisible quality assurance team.
    Doctor likes this.
  17. Shanj

    Shanj Well-Known Member

    and nonexistent interest in what client admins want.

Share This Page