Comments
-
-
Mike Finko 11 Dec 20 15:35 GMT-0000
tiki-admin.php?page=_ pages__
- Good point about "on the tiki-admin.php?page=___ pages", I didn't think about that. I would say that if you create 'groupings' in one area, than best to stick with that everywhere for consistency, so most likely a name of the topic, than dropdown 'Icon + name'.
Same grid but background color- Sounds like an option, I would need to see an example (I can't do this, it's beyond my skill level). If you or someone could create something simple, than we could add it as an option.
Which Icons in which categories- I fully expect there to be discussion about this, mine was only a starting point.
- I just double checked, each of the Features I have listed in 'Core Features' has the first check box as 'Activate Feature', so in the 'Features' section, it just duplicates them.
- for Marketing purposes, I believe a new user will be more interested in going to 'Wiki' 'Tracker' or 'Calendar' first, it will be more clear than heading to an Admin section which can draw them into other configurations and than get lost. Second, since Tiki is so big and comprehensive, we have difficulty of 'retaining the viewers interest', or, the lines get blurred between the importance levels of the features that they don't understand Tiki. If we make the 'Core Features a focus, and, keep repeating it everywhere, than it will be much easier and clearer to market Tiki.
Issues with Features in Categories- 'Categories' in User Features
- my logic here was that 'end users' are ultimately the ones who interact with Categories (after Admin or a manager set's them up). Yes, this one could easily be in another category (you mention 'Content Management', though I don't have that one, should we add it? what else would be grouped under 'Content Management'?),but if we put most of them right back under one heading, it will be a very lopsided Categorization. I believe the ultimate goals would be to spread them around for ease of use. Though we need to define our goals for the re-organization, so I will add a section at the top.
- Items other than Performance in Website Optimization
- as I mentioned above, I was initially guided by spreading them around
- MetaTags - I don't use them, didn't even know what they were until I read the description 'Information to include in the header of each page'. So this could easily be Admin, but since that category is already overburdened, Website Optimization was a good second option
- SEF URL and Search both impact site speed so, once again, yes, Admin is a good fit, but if the goal is to spread the Features around a bit, Website Optimization fits will for both of these, IMO.
- as I mentioned above, I was initially guided by spreading them around
Completion before FOSDEM 2021- no, this has nothing to do with the presentation, I just mentioned it as the reason for why I brought this subject up.
- that said, I strongly believe that too much 'consensus' leads to stagnation, and we should have deadlines. If someone ones to have a say, please step-up, productively contribute, otherwise, there should always be deadlines. Sure, some issues may arise, but they can be fixed in future issues, nothing is ever perfect.
- finally, if there is a stalemate, or even consensus, than we do what I did at my small messenger company and pull out a coin and toss it to decide a winner. Best management strategy ever as you are not to blame, the coin is!!(:biggrin😊
-
Mike Finko 10 Feb 21 18:00 GMT-0000
Thanks for adding, Gary.
I think it's a unique and interesting approach. Only do not believe it's good for Tiki with it's current 'onboarding' issues, as well as limited developer pool.
I would vote for a total revamp:
1) get rid of the row of short cut icons at the top - maybe a lot of people use them, I do not use them often, I still get confused on some of them.- plus, they are not all there now, what happens with more growth? more discussions about which ones to add/delete which can drag out for months or years?
- possibly under a 'toggle' but that's more work, not the 'simple' approach which Tiki needs now - maybe when we reach 8000+ outside developers and 8 full time paid developers like 'Home Assistant' we can consider this.
2) simply copy the example above from 'Project Open', which is really just a 'universal' layout, same in WordPress and most 'stores' and, well, most sites.
- this simplifies onboarding and allows for easier growth of Features.
- yes, would could incorporate some type of 'show/hide' but that just complicates things, Tiki already has a major issue with not enough developers, in our case, simpler is better
- mobile (as Bernard points out below): this simpler interface would scale better
3) less colors is more professional, and, once again, simpler to maintain
br,
Mike-
I use the admin icons if I happen to be on tiki-admin.php (like maybe I forgot the exact URL to a feature admin page). With the icon fonts, the meanings of the icons aren't as clear as they were with the old image icons, due to our having to assign icons from a limited set. But with the labels on the anchors, there's no problem. I think by grouping them as I did and adding section labels and colors, the usability would increase quite a bit.
A benefit of having the button grid on tiki-admin.php is that the grid is replicated in simplified fashion on all the admin pages (with URLs like tiki-admin.php?page=...), so a familiar interface is repeated. (I hope the admin icons can be improved for better understandability in the future — I have some ideas on that.)
As for not all the buttons being there now, and what happens with more growth, well, whatever that's missing and needs to be there can be added — it was not added for some reason, or due to an oversight I suppose — and more growth means adding an icon for what comes along. This would be the same issue whether the icons are in a grid or spread out in sections down a long page.
I don't know where you are talking about using a toggle so can't comment.
I don't especially think the examples from Project Open are very attractive and in fact look dated to me. I always get a feeling of retro interface when I use cpanel.
There's no maintaining to be done regarding the colors — the standard Bootstrap alert color classes are used, which are supported in all themes. No ongoing maintenance would need to be done for this button layout in regard to colors.
I don't agree that it's necessarily more professional to use fewer colors. (Do an image search at Google, etc. for "Admin Dashboard" if you think modern control panels aren't colorful.) When colors can be used to distinguish page elements and convey meaning, that's good user interface design. The particular colors can be more muted shades, defined in the theme, of course — the small-grid examples above are probably more "colorful" than we'd want to use.
-
-
Mike Finko 11 Dec 20 16:12 GMT-0000Another common option for grouping large sets of Features is to have a left 'sidebar' with a 'Category Name + Icon', than in the area to the right it displays only the sub-options.
-
Bernard Sfez / Tiki Specialist 10 Feb 21 06:33 GMT-0000Thank you Mike for this awesome work !
My 2 cents;
We should evaluate the "real life" usage of the control panel and determine targets (kind of users) so we can offer a better UX.In "normal" life I would say that control panels are not that much used by admins however it is their first contact with Tiki. So it should be clear (not over-crowded or heavily coloured), there should be a kind of balance between "important/set it first" and "most used". IE: General is essential to start with, but once a Tiki is configured it is rarely visited anymore. New comers should not only enjoy easy/clear access to feature and option, there should be also some educational thinking (well done panel help users to discovers tools that may help them depending on what they already use).
"Developers and consultants" have another life that open them most of the time to test, change and check stuff... They should enjoy a better interface but they are able to find their way and look "under the stone" to find what they want.
Day to day features should not be hidden and accessible with a minimum of clicks. Those features are to be determined but I’m thinking as things like: Users Administration, logs or stats, etc)
My suggestions:
- Colours can be discussed hours and issues may rise as they are depending on the themes. I would suggest we use bootstrap colours (primary, info, secondary, etc). Easy to fit in and everyone had already a sense of what they are used for.
- We must provide a better mobile interface. While Mobile vs Desktop % usage are now a kind of stable since 2018 (+/- 55% mobile 45% desktop - googled and check a few results) it should be possible to admin conformably Tiki from a mobile.
- The top smaller icon should be hidden under a toggle area to spare room and clearer screen
- We could also use a toggler for admin panel sections (global, content, etc)
- In my dreams ? admins should be able to drag’n’drop control panels icons so while we have a solid default, admins will be able to arrange icons the way they want.
-
-
Bernard Sfez / Tiki Specialist 11 Feb 21 07:54 GMT-0000
Reconsidering...
- We should have the same approach as Tiki and use a left or right sliding panel to place panels names (sections)...yes we have sliding left and right col already !
- I don’t use the top icons admin (but it may be useful for mobile so I still think it should be toggle-able (optional)
- Colour if used should definitely be based on primary, info, warning, danger, success, etc (bootstrap) colours.
- I still think we should be able to reorder if we want (drag’n’drop)
Why about discussing this during our next TRM (February 2021 second hour) ?-
Mike Finko 11 Feb 21 08:37 GMT-0000+1 for discussing at TRM.
-
Mike Finko 11 Feb 21 09:43 GMT-0000
Jono Bacon, Feb. 11, 2021:
"Collaboration is great, but consensus-based decision-making isn't.
Instead, pick a Directly Responsible Individual (DRI) who:- Is accountable for delivery.
- Coordinates resources/people.
- Provides reporting.
DRIs can come from any team/level & is a good opportunity for career growth."-
Responsibility doesn't work without competences, i.e. authority. Also, you cannot place accountability on volunteers.
-
Mike Finko 12 Feb 21 12:44 GMT-0000
Are the 'Admin's just 'volunteers? Seems that anyone who commits to being an Admin should also commit to some level of responsibility/accountability. Maybe they are already overburdened, I don't know? That's why we need a 'Community' to help out (outside of 'devs' it's practically non-existent), but to build a Community you need a 'Monetization' model (most common is the '3rd party plugin' model, but this does not fit Tiki) which is being discussed somewhat. However, this all boils down to the 'root' problems with Tiki.
That's why I am lobbying for to fundamental and structural change to Tiki in the form of 'One Version of Tiki' so that a more realistic and sustainable approach is taken, focusing on strategic plans (short/medium/long term plans, currently there are only rough 'long term plans') .
btw, you seem to be quite active and helpful on the Forums and Dev Buglist, how about joining us for the monthly Tiki Roundtable Meeting this month?
br,
Mike-
"Seems that anyone who commits to being an Admin should also commit to some level of responsibility/accountability."
As I wrote, responsibility without competence doesn't work anywhere. Would you accept additional responsibilities from your employer without getting competences to actually perform the duties that come along? I don't think so, at least I won't.
At current, Tiki Wiki, from my observation as an outsider, is in a pitiful state. I learned to know Tiki on version 1.something and saw it grow, a great piece of software carried to more and more height by a large flock of volunteers.
Today, in my observation, Tiki is overgrown and hardly manageable by admins and devs alike, and the number of devs has gone down considerably. Bugs can lie in d.t.o for years or even decades with no one doing anything to them.
Tiki's illness is commonplace in the FOSS community. It is, I have to admit it is true, much more "sexy", much more rewarding, to write new code for new functionality than to do the chores of unit testing, code verification, code maintenance and bug hunting.
That is the root cause (to speak in ITIL terms) of the problem.
If responsibilities would be placed on the volunteers, in the short term it might lead to a more stringent bug-extermination result, which would be positive. But in mid and long term, it will IMHO lead to even more devs leaving with very bad consequences.
In my opinion, Tiki would need a moratorium on new functions, LTS should be frozen in this respect, and new LTS should only be begun once a level of bugfixing has been reached on the existing LTS (that level would have to be decided/agreed first, of course, but I would say 90% is fair.
Today version 18 is an LTS that is - that is Tiki's claim! - another two more years in maintenance. In reality many devs do not look at bug reports when 18 is written on them (I must, to be fair, also say that there are some like Jonny, Gary, Lucy, and some more, who do read my bug reports and occasionally find the time to do some fixing).
Because of Tikis deplorable state I have given up on advocacy for Tiki. I cannot (being a professional software tester, by the way) recommend this software whole-heartedly. Tiki has IMHO become a niche product, and the bugs are legion.
But enough of my ramblings as a disappointed long term user of Tiki...
-
Marc Laporte 16 Feb 21 14:54 GMT-0000@hman: did you receive a mail in private a few weeks ago of a dev who offered to help you?-
Replied to
I did receive an e-mail from someone I did not know asking for a short summary of the "umbrella bug" I filed on d.t.o. (about missing tra() on texts).
The mail was VERY brief and not in the best of English (even a typo in dev.tiki.org) and on a day I received large numbers of spam. Therefore I decided to wait and see if there would be signs of this user on d.t.o, but I did not see any activity. The mail came directly from a Google mail account so was unsure whether to regard this as spam or not. I see now that the user has sent a second mail, which I didn't see/read.
-
Replied to
I did...
@hman
We recruit junior developers to train them up. They are learning Tiki.
One of the ways to learn is to fix bugs and add features. However, many of the enhancements require discussion or to know Tiki well enough.
You have made a lot of good suggestions that just need to be done. I don't want them to wait any longer. He can convert these good suggestions into merge requests which can be promptly be merged in.
English can be 2nd, 3rd or even 4th language for these devs. But they are smart and will improve.
Can you give it a shot?
Thanks!
-
Replied to
Sure. But this is news to me, I did not know anything about that from the e-mail, perhaps those junior devs should introduce themselves, and say that they do act "in official mission". When you say "recruit", do you indicate that there are paid devs? Didn't know that either...
At least this would take the guesswork out of it, meaning that I do not know at what level I could talk to those guys.
When they want/have to learn the inner workings of Tiki, then I am not of much help, I know only those pieces I layed hand on, and that largely focuses on translation and the huge construction site that is called a calendar. Hard hat area! 😊
I will give the guy a reply today, promised. -
Replied to
Sure. But...
I probably wasn't going to make this public, but since you ask: Yes, they are paid devs. It's an experiment funded by EvoluData.com to
- Help the Tiki community
- Train Tiki developers for EvoluData
You are the client so you express needs from the point of view of a tiki site admin (when I click here, it should do X instead of Y) and they figure out the code. And the eventual merge requests will be reviewed by an experienced dev like Fabio or Roberto.We usually get them working on internal projects but I believe this could be more of a win for the community. And it could be more scalable.
Thank you!
-
Replied to
I...
I applaude the idea to bring some professionalism where it is needed. The biggest thing IMHO is the largely dysfunctional calendar which in my point of view is a disgrace for Tiki (no offense for those wrote it).
I also hope that this programme could bring more internationalism into Tiki.
Also no offense, it is my observation that Tiki is (like so many pieces of software world-wide) carried by a US-biased view of the world. I see this in SO MANY software day in day out, that simply assume that a month is written before the date etc.Personally I get pressured by my users to get menus up and running.
And there are some crash situations that need to be adressed.
-
Replied to
I...
Calendar will improve in upcoming versions because
- We now only have one interface that we converge on: https://doc.tiki.org/FullCalendar
- Tiki webmail is dogfoodable so calendars (and contacts) will be used more.
US-centric: There are actually very few influential Americans in Tiki. But we often do default to US stuff just because...Menus: They need work. Not trivial. I am hopeful about SmartMenus.
Crashes: Please show them to your assigned dev. Likely easy to fix.
Thanks!
-
Replied to
Calendar...
Well, in 23.0svc there a many of the bugs that I reported for 18.8's calendar still present, and that includes hardcoded (!) m/d order and leaving out the year from translation.Regarding menus: Since they do work on 23, perhaps only a debugging is necessary to find out why they seem to write-protected on 18.8.... Regarding crashes: They are all on d.t.o.
-
-
Mike Finko 16 Feb 21 15:56 GMT-0000
Hi hman,
I found an interesting post on LinkedIn about 'Social Capital' in Communities by Harvinder Singh Minhas (actually reposed by Jono Bacon), I would like to know your thoughts, see a little bit lower. But first...
You use 'hman' as a login, would you care to reveal who you are? Remaining anonymous is fine, but using a real name would add more credibility to your arguments (many of which I agree with, some I don't).
Lastly, before the article, I disagree about your choice of 'root cause' for the problems of Tiki of "...unit testing, code verification, code maintenance and bug hunting". IMO this is a 'symptom' of a ship that is just too big (root cause). But, we all have our opinions.
Post 5: #SocialCapital - Currency of CommunitiesCommunities are made of volunteers
Members join,engage,contribute & collaborate out of their own free will
They are not in a paid job
So,if a member contributes meaningfully in the community,it generally gets noticed,accepted & respected by other members
This is called as building one’s #SocialCapital
There is no objective way of measuring one’s Social Capital
However,as you see around your communities,you will see some people having more influence than others in the community
They have more social capital
Social Capital is gained when a member focusses on #Giving to the community & serving needs of other members (through sharing her expertise,knowledge,networks,finances etc) in a respectful manner
Similarly,it is lost when a member is too self focussed,argues with other members,does too much of self promotion (sharing her talk sessions her awards,promotion of her business, spamming etc)
A community manager’s role is to nudge members to build their Social Capital & to avoid activities that reduce their Social Capital
-
Replied to
Hi hman,...
I totally agree with that. But the problem is, and here I speak as a volunteer in working for a non-profit human rights organization for decades, that it is MUCH more attractive for people to work pro bono if it is for "real people", and that is: People you know. People who tell you in your face that your contribution was valuable .Non-profit work without direct contact becomes scarce, and in pandemic times I fear might get extinct. Non-profit work on the whole has taken a downturn across the board since its peak in the nineties. I see the membership in my org ageing, only few young people coming in to replace those who passed away.
Sadly I have concluded that the picture of unselfish humans working for the "greater good" to some degree does not stand the test of reality.
The consequence is that there are vast numbers of volunteers working e.g. for a food bank (which of course is highly positive), but only few people who are willing to do help in the administration of an org. -
Replied to
Hi hman,...
Regarding anonymity: On the internet I prefer to reside behide my pseudonym, but in private conversations I have no problems to reveal my identity. We are living in the age of omnipotent companies like Google seeking through every bit on the Internet to generate and SELL consumer profiles, which I do not want to feed.
So I do not hide myself, but I prefer not to feed the data monster. If you e-mail me, I can tell you who I am. But this much can be told (because its written in lots of places): I have studied computer sciences and work for a large datacenter in Germany as a professional software tester (ISTQB) and quality management auditor (QMA). I use Tiki for private use and the use of the aforementionen non-profit org. -
Replied to
Regarding...
It seems like you are in a good position (e.g. experience) to recommend some tools (preferably php based) to add to Tiki and automate some of the testing and QA processes. Even as a person with no knowledge in your field, I understand automating even 30% or 40% would be be unrealistic, but surely you know of some tools that Tiki could implement to at least catch some of the very big problems, or maybe 10 - 20% of the others? Currently it's 100% human testing, which I have a hard time believing that at least some of that can't be automated, particularly given the current trend of automating everything (e.g.' RPA' and now the even trendier word 'hyperRPA', coined by 'Gartner'!)).
If you are interested in implementing some solutions, great, if not, your recommendations would be valuable and someone else could implement.
br,
Mike
p.s. I was like you, and hid from the 'Machine' before, but than realized:
1) life is too short
2) it's about balance and 'reasonable' safety, not 100% -
Replied to
It seems...
Data privacy is WAY more important than most people realize.
Currently, insurance companies "grant" you a rebate if you get rid of data privacy and give them a DEEP insight into your driving style.
Most people grossly (!) over-estimate their driving skills and think "this will be a bargain".
They will only wake up when they have an accident and their loss of data privacy gives the insurer the proof of how risky their driving style really was, therefore giving solid evidence of why they have to INCREASE your premiums.
And very soon, no one will be offered a rebate, but everyone resisting the spying will have to pay a higher premium as a default.
Or look at the boom (!) of "health gadgets" which will feed health insurances with many people's lack of sports, couch-potatoism and stream of junkfood leading to high blood pressure.When you wake up and realize you lost data privacy, there is no way back.
Another perfect example of how modern tech gives you the ability to spy on your neighbors: I have the "really free" version of Germany's corona tracing app (the version of the Governement is FOSS, to be sure, but it is merely a GUI to an API layer made by Google which is (of course) totally undisclosed. NO ONE (except for Google) knows what they are doing with the data.
The governments's corona app won't run on my Google-free Android, so I got a really FOSS fork called Corona Contact Tracing Germany which runs on MicroG to replace googles API. Now the government's app gained a new function, which CCTG inherited: It shows you how many contacts you had PER HOUR for the last fortnite. The data is pseudonymized, but now I can exactly (half hour precision) tell when my neighbor is getting up and switching on his smartphone... I can even see how long he sleeps on week-ends etc.
Now that is possible with pseudonymized data. Imagine the possibilities if the data could really be de-anonymized... -
Replied to
It seems...
Regarding automated testing: Yes, I know a couple of tools, but they are mostly expensive, and ALL of them are hard to use. The learning curve is rather steep, and forget the illusion that some tool manufactures like to create: You cannot save an understaffed project by introducing test automation. It will NOT save "a lot of work". It can do that in the (very) long run, but at first you must heavily (!) invest in manhours to program those tests. The tests do not run by themselves, you have to
a) meticulously (!) define what your units have to achieve and
b) how metrics would work to measure success or failure
c) program test scripts that perform abovementioned metrics
d) You have to evaluate the results.
You can save on manhours if you have to do a lot of regression testing, for instance, if you have to test your units against everchanging other parts your project will run against. This is most useful if your unit stays more or less unchanged, but the "world around you" changes daily. If you incorporate SCRUM, for instance , you will have daily (!) new builds (called sprints), and then it saves manhours, because you can prove your unit still runs as intended by starting yet another test run.
But the amount of work to evaluate a complex unit can easily meet or exceed the amount of work needed to program the unit in the first place...
This is no viable way for understaffed projects, and in my perception Tiki is one of them. Wikipedia boasts "more than 300 developers and translators", but I do not see that many here on d.t.o...
-
-
Jonny Bradley 19 Mar 21 16:50 GMT-0000Apart from this thread being in the wrong place (it's not about the control panels revamp is it?)... one of the reasons we are so short of developers is that we have some capable developers and experienced tiki users who point blank refuse to contribute even though they clearly have the ability and time.
It's quite frustrating, please excuse my ramblings... (:eek😊
-
-
-
-
Bernard Sfez / Tiki Specialist 17 Feb 21 07:52 GMT-0000
Very interesting to read, thank you both.
There is room of course for a "Strategy" discussion for the future of Tiki...Next Virtual Tikifest ?
-
Mike Finko 19 Mar 21 18:03 GMT-0000
First Design Proposal - very nice! Awesome job, Katy!
Not nearly as flashy and unique as Gary's but IMO, less information all at once (e.g. simpler) is always 'better', or at least easier to navigate. If the goal is to remove obstacles for 'on-boarding' new users, this step definitely helps.
Might be good to make the main category field names (General, Content, Design, etc.) a few font sizes bigger so they stand out more.
br,
Mike-
luciash d' being 🧙 22 Mar 21 20:24 GMT-0000Thanks! Katy made the section titles a bit bigger as suggested by you. It will be visible on the new image exports soon. We will also include link to the design file on Figma, so you can zoom in/out and review the designs better directly there...
-
-
Bernard Sfez / Tiki Specialist 20 Mar 21 00:08 GMT-0000
@luciash @Katy
Nicely done, thank you.
My 2 cents:
- It’s a bit dark... May be a different colour for the access menu and preferences search field than the left col ?
- I would move the advanced/basic switch right (aligned with the main page left) (keep all the left to for the logo)
- Remove "system menu" (it is just taking room)
- Reduce the white space around things (look and feel title can be moved a little up)
Plugin ImageFile not found.-
luciash d' being 🧙 22 Mar 21 20:27 GMT-0000
Thank you Bernard for your comment! We reviewed your "2 cents" 😊 but we agreed just on a slight white space reduction. Your example feels already too much cluttered and it doesn't look that modern/fresh imho - it looks too much too close all together (reminds me the old Tiki themes for some reason? 😀) and too close to the sidebar and topbar.
White space is good! It was proven many times in web design articles. But don't worry, it will be responsive and on smaller screens and mobile it will be reduced appropriately to save the screen space.
Regarding the top bar we prefer to keep it in the dark gray color for dark navbar selection and maybe light gray for the light one but not to complicate it with any other color as you never fit in everyone's colors preferences, so best is staying neutral. We also wanted to keep the Basic/Advanced switcher together with the filter icon above the sidebar because it affects what will appear disabled/enabled there and on smaller screens it would occupy too much horizontal space of the top bar so then the search etc. would not fit and cause wrapping or other overlapping issues.
-
Spacing should be set by Bootstrap classes IMO so whatever is appropriate for the theme can be used. (Maybe a larger font size is needed if color contrast isn't as strong, for example). And this makes it easy to override the stylesheet rule with custom CSS in Look & Feel admin for per-site customization. So whatever is created initially should just be a starting point, one that lends itself to easy modification.
Hard-coding colors is not a good idea, in my opinion. Instead, use classes that 1) are already part of the Bootstrap/Tiki code so color coordination is automatic, and 2) are made to be defined as required by the theme design and site preferences.
-
Bernard Sfez / Tiki Specialist 23 Mar 21 08:31 GMT-0000
As Gary says, let’s use our default (bootstrap classes) for spacing as well as background.
It will also reinforce consistency overall.Whatever you do is good and a super improvement already !
-
;){kind=link}
;){kind=link}
- Malformed search query: SQLSTATE[42000]: Syntax error or access violation
- Plugin wishes is failing on the page Regressions-in-26x and show.tiki.org
- No dot allowed in page names, but page generated anyhow
- Fatal error when changing banner type or creating a new banner zone
- WSoD on profile using array type preferences
;){kind=link}
;){kind=link}
Comment from Gary:
Hi,
I agree that the collection of admin icons isn't easy to understand and it's hard to find what you're looking for, etc. (The unclear meaning of some of the icons is a big part of the problem, too.) I believe the logic for the current arrangement is to put the most commonly used items at the top, and the things used less often at the bottom. Of course this is only possible to approximate as everyone has a different preference. But it's good to think about reorganizing them if it helps their usability.
A problem with categorizing/grouping them under headings is that it takes up a lot more space. This isn't an issue on tiki-admin.php, but would be kind of wasteful of space on the tiki-admin.php?page=___ pages. Do you propose to repeat the grouped icons layout on those pages also, or stick with the grid of icons?
It would be nice if the icons could be rearranged and grouped but still be in a grid as they are now. Maybe alternating background colors could be used to distinguish the categories. Headings could be inline, the same size as an icon or double-width to stand out better. Just brainstorming here.
People probably have different ideas about which icons go in which categories, and the order in which things are listed. For example, it seems natural to me that the Features icon to turn features on and off would be listed before the individual features. In fact I would put the "Admin" icons ahead of the "Core features" icons, as being more basic.
There are bones to pick with a number of the icons' placements, like why is "Categories" in User Features; I would say it applies to more to content management or overall site organization. And I'm not sure why items apart from "Performance" are under "Website optimization".
Getting into all the details is too much for this email, but I'm sure there are lots of opinions about what would go where, and if there are categories/headings, what those should be. Thanks for revisiting this. Is it really necessary to reorganize the arrangement of the icons before FOSDEM, or are you just wanting to be more familiar of where everything is? I don't think rearranging the icons can be done without more input from others.