Figure out a way to organize contents of chrome folder about firefox-csshacks

[EstherMoellman]

The external webpage with filters is a very nice idea. My only concern is the time and attention this webpage may need, not just to be created, but also to be maintained. It is up to you, it is all about how much time you're willing to invest here. But if you decide to create a webpage, then this has an endless potential, because (for example in the future) you also can add images and variables to filters, so users can play with variables, seeing changes on images (in real-time), allowing them not just to use your CSS scripts, but also to customize them directly on your webpage.

Having said that, I always like projects by stages. Between your current GitHub' repo and your possible external webpage, I think you may have stages. And perhaps is more efficient (less time consuming) to start first doing something by organizing (a bit) your current GitHub' repo.

The alphabetical order is not good, because depends on code name. And considering that at present moment your codes have no categories, many code names are confusing. I believe categories/subcategories will help users to find what they need, and also will simplify code names.

It's true what you said about superposition of categories. But I think this is not applied to most of the codes (which perfectly will fall inside one category or another). My suggestion is to start creating the most important categories: a) NAVBAR b) URLBAR c) TABBAR d) TABS e) etc... and time will say if you need to create or change stuff. For exceptions where codes may fall in more than one category, I believe will be enough to leave a comment inside the empty category, informing users that "X" code can be found at "Y" category.

Also is true what you said about links that need to be changed at current codes. But honestly, this is just a mechanical one time consuming task. And I volunteer to help you to do that. If you create the categories/subcategories, you classified your current codes inside these categories/subcategories, and finally you change code names... then even a monkey like me (LOL) can help you to update the links inside each code... piece of cake : )

It's worth mentioning that GitHub' repo has other benefits, for example and considering constant Firefox' updates, IMO is easier to maintain a GitHub' repo than an external webpage. Also, GitHub' repo has lot of useful info, for example at "commits" is possible to follow changes, and users can learn a lot with these "commits".

[MrOtherGuy]

Just a a few examples why folders (or filename prefixes for that matter) would just not work.

Oneline interfaces. Do they belong under nav-bar or tabbar? Or neither. What about different styles that move some or all of them below content?

What about some of the _patch.css files that enable compatibility between few styles? Should they belong to one folder or another?

Also is true what you said about links that need to be changed at current codes

What I meant is links on external sites such as reddit or whatnot. No way I'm able to fix those.

By separation to folders the only sane option I think is to create few really generic folders. There might be a way to name them such that there is a minimal overlap (but I don't know what that is yet) But still, the majority(?) of styles wouldn't fit in any of them - so that's no good. Or at least not any better than the current system which kinda adds a filename prefix to describe what it affects, such as autohide_x or dark_x or hide_x

Point is, at this time the separation to folders isn't too much better -if at all - than current behavior. So I would rather not do anything about this at the time unless the solution has no (or only very minor) drawbacks.

Additionally, I would just use the github pages feature to create this "external" browser - not sure if it would work through the repository readme but that's something to be experimented on.

[EstherMoellman]

Understood. Just adding few final comments for your mind food... I'm not denying problems by using categories/subcategories. I'm only saying that:

• Categories/Subcategories will work at least for 80% of your current codes. Therefore, this is not only a good solution for most of your codes, but also this is a better solution for your current non-categorized repo. Even if you don't change code names, the simple fact of putting codes inside categories/subcategories, this will help a lot users to find what they are looking for. It is common-sense: It is faster and efficient to look inside categories/subcategories, than to do that in a long unified list of different codes (sometimes codes with confusing names). Categories/Subcategories not just will accelerate searches, but also will help with code names. This is profit when compared to your current repo.

• We should not build any logic focused only on exceptions. For every exception you pointed out in your previous message, seems to me we can find a quick and simple solution. Nope, never will be perfect! But if can be easily done, and if it works for 90% of your current codes, then IMO is worthwhile.

Important to mention that I agree with your vision. It looks solid and great. But as I said in my previous message, I'm afraid about the time/energy your vision might take you. Thus, my suggestion is a first primitive step, imperfect, incomplete, uglier than your vision, but my suggestion might be simpler, quicker and good at least for 90% of your current codes. As I said, up to you! If you're willing to invest on your vision... yeah, fantastic, because is better and nicer than my basic suggestion.

[MrOtherGuy]

I did a quick test of how folder based categorization might look like here:

 chrome
  | autohide
  | buttons
  | dark-mode
  | hacks
  | legacy
  | popups
  | tabs
  | toolbar-order
  | urlbar
  | _blank_page_background.css
  | _color_variable_template.css
  | _hide_toolbox_top_bottom_borders.css
  | _linux_gtk_window_control_patch.css
  | _minimal_in-UI_scrollbars.css
  | _multi-row_bookmarks.css
  | show_window_title_in_menubar.css
  | _window_control_placeholder_support.css

So, there's 9 categories and 8 files that don't really fit in any of them. Moreover, now it's pretty annoying since stuff like minimal_* files are split into multiple categories. Meanwhile categories like autohide have stuff that people probably wouldn't think is actually "autohiding" such as show_navbar_on_focus_only.css - it's perhaps closer to "hide things" category yet things like hide_tabs_toolbar.css is in tabs section but for some reason autohide_tabs_toolbar.css is not.

Point is, the file a person is looking for might be in one category or the other depending on what the person who is looking for it thinks about it. That's much worse than even reading through the whole list of file names. And, the repository can be searched for partial filename anyway, so you don't really have to read through the whole list if you don't want/need to.

IMO, folder based categorization does not yield enough benefits - at least not without rather serious drawbacks. I really can't say that it would be objectively better than current system. I know I'm biased because I (mostly) know what even exist and what does not, but that's been accounted for.

That being said, I could clean up a tiny bit; there are some styles that are A) totally outdated or B) not working at all anymore or C) hacks/styles that are much less stable than anything else. I could create those hacks and legacy/deprecated folders for those. That would be about 15 files in total currently which is indeed a good portion of the total.

[EstherMoellman]

... of course you always will have the last word, and you always will do what you think will be the best for you... but with all due respect I still believe many of the so-called exemptions you found, each one may have a simple solution. For example:

• LINKED CODES (Reddit etc): You may keep the current old repo, but delete content files, and insert a message inside each file, informing about the new repo. Then, create the new repo with categories/subcategories. So, every linked code will work forever, always the user is going to be redirected to your old repo, there he will find an empty file but with the message about the new repo.

• AMBIGUOUS CODES: If a code may fall in more than one category, put the code in just one category, and in the other categories put an empty file with the same name of the ambiguous code, but inside this file put a message redirecting to the real code/real category.

• CATEGORIES: From your 9 categories, I think for starting is more than enough: NavBar, UrlBar, TabBar, Tabs, Buttons/Icons, Miscellaneous. For example, you don't need Dark-mode as category, every dark-mode code you currently have will fall inside one of the categories above. Same example for your Popups category, no need for that, it perfectly may fall inside one of the categories above. Same logic for: Hacks, Legacy. Please remember that if you want, you also may use subcategories inside my suggested 6 categories. In this case, subcategories always may be repeated between categories, but categories never will be repeated, are unique. For example, you may have NavBar/Dark-theme, and UrlBar/Dar-theme, or NavBar/Popups and TabBar/Popups etc.

• 8 ORPHAN FILES: You perfectly can put them inside Miscellaneous category. For example, "show_window_title_in_menubar.css" and "_window_control_placeholder_support.css" may fall inside Miscellaneous/Support. And "_linux_gtk_window_control_patch.css" inside Miscellaneous/Linux. And Miscellaneous/Bookmarks: _multi-row_bookmarks.css. Etc. PS01: If you have lot of bookmarks codes, create a category for bookmarks. PS02: "Linux" might be always a subcategory, which will fall inside each category.

• INDEX: A general index inside root chrome folder, will serve as a map to identify all your categories/subcategories/codes. Inside this general index, you may add small (very small) descriptions, which will help users to understand the function of each code. These small descriptions will solve issues like you pointed as "minimal_* files", "autohide", "autohiding", "show_navbar_on_focus_only.css", "hide things", "hide_tabs_toolbar.css", "autohide_tabs_toolbar.css" etc. Also and in a second stage in the future, you can add images or videos or etc inside this general index... and this may kill big part of the problems you raised in your previous comments.

• CODE NAMES: After creating your categories/subcategories, I suggest you to simplify code names, because their parent category/subcategory already will be self-explained, and there is no need to put this info in the name of each code. For example, multirow codes inside "Tabs" category, they don't need the word "tabs" inside their names. Or dark-theme codes inside "Dark-theme" subcategory, they also don't need the word "dark-theme" inside the name.

Is this going to be the perfect solution? Nope! Not at all.
This is just a simple solution, basic, primitive, and can be done in less than 48 hours.
And this simple solution, even imperfect and incomplete, is an improvement when compared to current situation.
In the future, in a second, third etc stage, bit a bit you may improve this simple solution, for example by creating new categories, new subcategories, or by creating an external webpage that perfectly may work with this simple solution.

My impression is that you're thinking big and right, which is tremendously good, but it might take you more time and energy. If you're willing to invest that time/energy, then perfect!, be my guest, go ahead with your vision... I'll help you!
But if you don't have the time/energy for your vision, and you have a very simple alternative, possible to be done in less than 48 hours, then you should "flex yourself", and you should think by stages, starting with a simple stage, very basic and primitive, accepting that it'll be incomplete and imperfect, but knowing that you'll improve everything in future new stages.

From user point of view, my suggestion of simple categories/subcategories already will be a profit when compared to your actual situation. From user point of view, most of the issues you raised on your previous comments, they already exist on your actual repo. Some of your code names are too "techy" for users like me, and it takes a lot of time to open code by code reading your explanations and comments... and even when users do that, due to their ignorance, they don't understand your explanations/comments, and they are forced to copy/paste the code, to test empirically in order to identify "what a hell this code does". Now, in this context of ignorant users (like me), imagine, a simple category may solve tons of problems, because users don't need to understand the name of your codes, nor your explanations or comments inside each code, a simple category/subcategory already will help a lot users, because they can go directly to where they need. You perfectly may keep "techy" code names, explanations and comments in your own style... but the categories/subcategories will help a lot of ignorant users like me : )

[MrOtherGuy]

This is just a simple solution, basic, primitive, and can be done in less than 48 hours.

With all due respect, I don't think your proposed "simple" solution achieves anything expect adding even more complexity - and not only for me as the author but also makes it more complicated to use for everyone else. By all means, if one wants to fork the repository and go for all that trouble then they can certainly do that.

After reading all the arguments you have given I'm starting to become more and more convinced that a "separate" browser-page is really what needs to happen. I made a quick demo already, it's just a matter of figuring some things about how "tags" are going to be mapped (technically) to files.

[EstherMoellman]

No problem at all! Your house, your rules. Agree or disagree is irrelevant. We exchanged our opinions, so now the last word... the final conclusions always are going to be yours. My help is not based on convincing you about nothing, but in helping you to be convinced on your own conclusions. If your final conclusions are opposite to mines, then this is perfectly fine. So, I'm glad you are convinced about your own conclusions. Mission accomplished. And please, always keep counting on me (if I can help).

Just allow me to replay: "your proposed simple solution... adding even more complexity - and not only for me as the author but also makes it more complicated to use for everyone else".
You may want to know that I didn't invent the wheel, lot of GitHub' repos are based on the suggestion and arguments I gave you. I just shared with you the logic and layout found at many other GitHub' repos. And I still convinced that this structure is imperfect/incomplete, but any category/subcategory structure will be an improvement when compared to the current unified list at your repo.

[MrOtherGuy]

Well, I decided to experiment with tag-based route. It uses github pages to create a simple ui that can show styles that match some tag. This is very much work-in-progress and has wayyy too many unique tags but it mostly works.

You can see the page live @ https://mrotherguy.github.io/firefox-csshacks/

[EstherMoellman]

Few tags might be confusing:

• Minimal (too ambiguous for average users)
• 1-line (better to change to "oneliner" because is the most used tag in Reddit, GitHub etc)
• Flash (better known as "webpage white-flashing") / Blank + Background (it's a bit confusing with Flash)... 3 similar codes... isn't better to be under one tag?
• Staus (have no idea what do you mean with this)

But I don't think you need to change anything. I already know you for a long time, and I can perfectly see how this layout and tags with its code names, all reflect the way you think. They're a reflection of your mind. So better to keep these tags as they are now.

So, for solving confusions I suggest: Instead of changing tags, you simply can add a general index in the very beginning of the left-column (on top), as a tree map of codes. Also inside this index, a max of two short lines describing each code, will help a lot. If this is too much work for you, then a simple tree with tags and codes will perfectly serve as an index/map. For example and from user point of view, if I read the tag "flash", I never can image that inside I can find a "white-flashing" code (normally I'll associate "flash" with "flash player"). But if first I can see the index with the tree of tags and codes, and I can see that inside "flash" there is a code named "blank_page_background.css "... then the index is helping me to understand your tags.

Tags, categories, subcategories, code names etc... always are going to be very subjective. So, perhaps a simple tree map index showing tags and codes, may self-explain to users your logic.

Feel free to close the issue.

Big hug! : )

[MrOtherGuy]

By "tree" do ou mean like when you select a category it will then show you another layer of categories that exist in files from the first category?

I'm not really against it, but I'm not sure how much o a benefit it would be since the biggest category currently has only like 15 or sone items. And there are only a few categories that have even 10 items.

[EstherMoellman]

By "tree" I mean a simple plain text showing an index (it'll work as a map of tags and codes), inside this "INDEX" you can put category-names (tags), and code-names inside each category. Optionally, I suggest to add a short description inside each code-name. For example:

INDEX

      DARK-MODE
               blank_page_background.css: small description
               dark_additional_windows.css: small description
               dark_checkboxes_and_radios.css: small description
               dark_context_menus.css: small description
               dark_theme_aware_statuspanel.css: small description

The word "INDEX" should be the first tag on the left-column of your layout.
On the right-column you can place the category-names (for example "DARK-MODE"), and under the categories you can place the code-names (for example "blank_page_background.css: small description").
It's not mandatory, but if you put tags (left-column) in alphabetical order, also will be useful.

This "INDEX" will explain to users any tags and any code-names you use.
This "INDEX" allows you to use any tags/code-names, similar to the case of using a map in an unknown city... the user can ignore name of streets, by using the map he can find any name.
Users don't need to mouse-click each tag to see each code. The "INDEX" will automatically show all the tags, all the codes, and (optionally) all the descriptions.

[MrOtherGuy]

I'm trying to figure out what you really mean by this index and how it would behave. But I can't figure it out.

Users don't need to mouse-click each tag to see each code. The "INDEX" will automatically show all the tags, all the codes, and (optionally) all the descriptions.

Even ignoring descriptions, this list would have the exact same problem as flat file-name list on github, except much worse since a file will fit in multiple categories.

One thing I did try at first though are alphabetical categories. But it really wasn't good so I changed to sort-by-largest-category in hopes that stuff in largest categories are probably the most used. Still, since those category names are by no means final (I hope to reduce them about 40%) I might want to revise that afterwards.

[EstherMoellman]

Let's remember that since the very beginning, this request (your repo organization) was kind of irrelevant to me, or at least it was not a priority. Because of that, my original suggestion was very simple: Just to create very few categories and subcategories... and put there your codes. That's all.

Now, this your project with lot of categories and fancy stuff, is far away from what I requested.
I'm not saying your project is wrong. I'm saying that IMO, such project creates complexity, which ends requiring too much time/energy. I tried to alert about that in previous messages.

Well, now you have loooooooot of categories. And I'm not going to fight against you. I'm just trying to help you with suggestions that might deal with lot of categories.
The problem is that (as I said yesterday) categories/subcategories/code-names etc... always are going to be subjective, and more and more categories... this will increase more and more "subjectiveness". And yesterday I gave you few examples, one of them was an user looking for an anti-white-flash code. I can understand your tag "Flash", but I'm sure that many users are not going to associate your "Flash" category with "anti-white-flashing".
However, and as I said yesterday, the solution is not to change tags, code-names etc, because these tags and names reflect the way your mind thinks. It's your personal signature. And as a Dev, you should be free to create tags and names that you're comfortable with them. This is an important point, not to be missed.

So, only in this context above, yesterday I suggested the so called "INDEX".
Back to the example of an user looking for an anti-white-flash code, under your current project, if the user doesn't associate your tags with the codes he needs, the user will be lost. So, a simple plain text INDEX might help users to understand your tags. In this example, the user may see at your INDEX, that under "Flash" tag, there is a code, and a short description will help the user to understand where is the code he needs. Voila!
You may disagree or dislike the idea... it's perfectly fine. But the idea is simple and pretty clear.

Having saying that, yesterday I also said that only FEW of your categories are confusing or ambiguous. Therefore, most of the tags you chose, are fine! So, perhaps your project can be considered done, and you can close this issue.

In brief:

• INDEX is not mandatory.
• Short code descriptions inside INDEX... not mandatory too.
• Most of the tags you chose, are fine.
• Your current project is far away from my original request, and IMO you can consider it finished. With time, bit a bit, you can add or delete categories, change names, make improvements etc.

PS: To classify tags under "the most used" rule... IMHO it increases even more and more "subjectiveness". IMHO, every search will be much faster, if tags are classified in alphabetical order. Think about the time it will take from any average user, to read ALL your categories, just to identify the tag where probably the code is inside. You are doubling the difficulties, firstly because without INDEX, the user is forced to check each tab, to see codes inside. And secondly, because if tags are ordered by "the most used" rule, users are going to be forced to check all the categories until the end.

[MrOtherGuy]

I'm saying that IMO, such project creates complexity, which ends requiring too much time/energy. I tried to alert about that in previous messages.

This is very interesting, because from my perspective the experimental style selector thing and the system it uses to save that information will be much simpler to manage than folder-like categories like you proposed. Like, keeping file management easy was the exact goal I wanted to achieve and its the very reason it works with tags, not sub-folders or something similar.

And as I've said multiple times, I'm going to drastically decrease number of categories once I figure a good way to represent that. So don't worry. I just initially wrote some tags for files to test the page.

As far as the index goes, well I'm interested but I really couldn't wrap my head around what it looks and behaves like in your vision. That was my only problem with it. My problem is not its usefulness, but how it works in your vision. I believe you envision it in a rather different manner than the one that I could understood by reading your comment. Because, if I would create it in the manner that I understood, then it's going to make the index super-long since a filename would be repeated multiple times - once for each of its tags.

So I don't think we are on the same page of the indes here at all, I'm afraid I may need you to provide some specs for how it should be presented, how it behaves and what kinds of interactions user could have with it. Only then I can determine if it's a good idea or not.

By the way, non-alphabetical order of categories won't be much of a problem if the number of tags is reduced. But we really can't know which (or netiher) would be best sorting before number of unique tags gets reduced.

[EstherMoellman]

As I said, my original suggestion was: Very few categories, very few subcategories, codes inside them... and that's all. I'm totally convinced this still is the simplest solution, and your repo doesn't need more than that.
And I was aware about imperfections and many other issues you raised about this my suggestion... I just didn't mind, I was perfectly prepared to live with imperfections (as today I perfectly already live with your old repo).
Well, in this context above, your current project... is a bit overwhelming for my taste (LOL).
But my original suggestion wasn't a request!... it wasn't something for me. It was just a suggestion for you and for your repo. So, "what I think", "what I want", "what I like" etc... it's irrelevant. Here we're not going to be on the same page, we're not going to agree, I'm not going to approve your project etc... but the thing is that we don't need to agree, and you must forget my taste or approval, because again: This is not for me, never was my request... always was just a non-priority suggestion from my side.

The only focus is YOU and your REPO. This is only about YOU and your REPO.
It's a mistake to organize your repo according someone else point of view.
Your repo is your shoe, it must reflect your own mind, your own way of thinking.
You should feel totally comfy with your repo organization... and that includes the number and names of tags, categories, subcategories, codes etc.

So ignoring myself, and trying to help you, your vision, and your project, I suggested the "INDEX", "short descriptions" etc.
Yesterday I saw loooooooooot of tags on your project, they hit me (LOL), I felt lost in a jungle (LOL), but most of the tags were understandable, so I ignored the huge amount of tags. The problem was that few tags were really confusing/ambiguous, and I tried to conciliate your point of view with average user point of view, so I suggested the INDEX + short explanations. Yesterday and today I gave you practical examples of users that are not going to understand some of your tags, and because of that, these users are not going to find codes. The number of tags is irrelevant! The problem is that in your new layout/logic, if the tag is too confusing or ambiguous... the user is lost.

The problem get worse, if tags are not in alphabetical order.
Think as a computer, if the software previously knows that tags always are going to be in alphabetical order, then the computer never will read all the tags... it'll go directly to the related tags. But if tags have not alphabetical order, then the computer always will need to read all the tags. No alphabetical order will force users to have to read all the long list of tags.
This is easy to understand. As I said, you may disagree or dislike, but this is not a problem of understanding. You understand, but you disagree.

The same happens with the INDEX. You understand the concept, but you disagree. And why you disagree?... because it's an endless loop: Your tag layout/logic, with lot of tags etc... would demand an endless INDEX. You see?
As long as you defend the tag layout/logic, you always are going to disagree with INDEX, short descriptions etc... because in your mind these tools are going to became long repetitive lists of nothing... and you're right!... but you should note that the root of the problem is not the INDEX + short descriptions... the problem is the huge quantity of tags.
You may argue that this also may happens at few categories layout/logic. And no, you're wrong. Few categories may suffer from "subjectiveness", "ambiguity" and all the same problems as tags suffer... but few categories perfectly allow to work with INDEX and short descriptions. You see?

Now compare tags VS categories... which one is more subjective? What's the probability of number of tags needed VS number of categories needed? Which one can include more codes, a tag or a category? You may disagree/dislike, but IMHO, tags are far away more subjective than categories, at least when we talk specifically about Firefox and CSS. Even if you use few tags, IMHO you always are going to be more subjective than with categories.
As long as you increase "subjectiveness", you increase complexity (entropy), and you will need more and more time/energy to solve complexity.
My original suggestion with categories was primitive and imperfect, but was a bit less subjective than your tags project, so the complexity level on my original suggestion is more manageable than in your tag project. And while few categories allow INDEX and short code descriptions, tags creates endless INDEX with repetitive short descriptions. You see?

I perfectly understand your logic of tags because I know you! Nope, I don't know you personally or on your personal life. But I'm reading you almost every day since more than two years. And yeap, in terms of CSS, JS, GitHub, Firefox etc, I believe I have a pretty idea about "how you think". And your tag layout/logic, IMO is the perfect reflection of your mind. But as long as you will defend this tag logic, subjectiveness will increase, complexity will increase, and you will disagree/dislike with many suggestions, simply because this is the typical conflict between "more subjectiveness" = "more complexity". Your real bias always will push your perception in favor of your logic (tags), even if your logic might not be friendly for users.
Again, I don't believe you have problems in understand my suggestions. I believe you're married with tags logic, and this makes you biased to go all the way with tags.

Having said that, I still believe you can keep your tag layout/logic.
And I still believe an INDEX + short descriptions might be done.
For example, instead an INDEX of tags as I suggested yesterday, you may build an INDEX of codes. It'll be a simple list of all the codes (in alphabetical order). And inside each code, you can add a short description. And also, le pièce de résistance, the cherry on the top... at each code you can add a list of tags! What are your thoughts? For example: When the user opens your new repo, he can use your tags to find the code he is looking for. But if this user gets lost, he can open your INDEX of code-names, and because this INDEX is in alphabetical order, the average user quickly will find "key words" of the searched code-name. At the same time, the found code-name will provide a short description and the tag where it can be found.