Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for manual config files (Options, CSS, JS) #151

Closed
5 tasks
9z0 opened this issue Jun 1, 2021 · 9 comments
Closed
5 tasks

Support for manual config files (Options, CSS, JS) #151

9z0 opened this issue Jun 1, 2021 · 9 comments
Assignees
Labels
feature request help wanted Extra attention is needed

Comments

@9z0
Copy link

9z0 commented Jun 1, 2021

Multiple Electron-based projects allow the user to have their own CSS/JS run at startup.

This allows the user to customize almost any part of the UI/UX to their liking without burdening the developer (you) with requests (other than helping with the syntax if a user is stuck).


A few examples (existing issues) which can be implemented in this way:

And a lot more: adding/moving buttons, always-visible todo count, resizing bars/panels etc.

Even more complex features/bug fixes can possibly be implemented in case development stops for whatever reason.


Example projects which can provide ready-made methods for this are:

  • Joplin. It provides userchrome.css (for customizing the app UI) and userstyle.css (for customizing MD rendering). See here.
  • Notable.

It comes down to just reading a user-filled CSS file/JS file and running them on startup.


Tasklist:

  • Options

    • Unminify the user-preferences.json so that it can be easily edited. Alternatively, support a simple format, like ini along with/instead of the json file.
    • Simple comments in the file to indicate, in short, the function of each user-changeable option and its accepted values.
  • CSS

  • JavaScript

@ransome1 ransome1 added the help wanted Extra attention is needed label Jun 1, 2021
@9z0 9z0 changed the title Support for user-provided JS/CSS for customization Support for manual config files Jun 22, 2021
@9z0
Copy link
Author

9z0 commented Jun 22, 2021

I edited the issue title to reflect the need for a solution for advanced editing while keeping the GUI simple.

Aside from customization, options in user-preferences.json should be expanded to allow the user to change the defaults in multiple areas.

I think this will benefit the advanced user while being easy enough for @ransome1 to add.

@ransome1
Copy link
Owner

@9z0 if you say allow the user to change the defaults in multiple areas, what exactly does this mean?

@9z0
Copy link
Author

9z0 commented Jun 22, 2021

@9z0 ah ok, now I understand what you are referring to in the other ticket.

What did you see it as? :D

I assume the typical sleek user has tried out a couple of different todo(.txt) apps and was amazed on how unpleasant many felt like and how much complexity had been worked into some interfaces.

  1. I can only speculate about others and my own experience will obviously affect my view, but for me, you'd be surprised (maybe not you!) how many of these apps miss basic usability features or have feature-breaking omissions. Among them one or more of:
  • No filters!
  • No search!
  • No sort!
  • One key delete AND no delete confirmation AND no undo.
  • Only accepts files named "todo.txt"
  • Filter options don't include none. You can't filter todos without context, for example.
  1. And those that do have most of the above right have ALL its features in your face in specific ways and are not customizable. So either the app is unusably simple or caters only to the developer usage habits and workflow.

A good design philosophy is to have sane defaults AND simplicity out-of-the-box AND customizability (and, depending on the case, extensibility). These are not contradictory. You don't have to choose; although I'll admit that it takes a bit more effort and vision to implement.

I do agree with you that many users could simply want a simple list to add and check, but I'd claim that this is offered already offered by multiple other todo apps. The "art" here is subtle intuitive design (think Apple) that the user wouldn't even think to mention if you asked them about the features of the product or what they like about it.

Fortunately, much of these cues and options are out there already and not too difficult to implement. For example, sleek itself:

  • puts setting icon and help in a corner out of the way but accessible.
  • moving todo options from a three-dot menu to context menu (one click either way). -> cleaner look.
  • click panel headings to filter by none.
  • panel close arrow that appears only if the user hovers on the separator.
  • etc

As long as the basic usage is as easy as possible, and features don't force themselves on the user, I think the simplicity of sleek (and todo.txt) is comfortably achieved. To be clear, at this point I'd take a todo.txt app that covers the basics over a feature-rich one; but my whole point is that we don't have to pick! It is all about how the features are implemented.

@9z0
Copy link
Author

9z0 commented Jun 22, 2021

Exposing settings in the config file is not a problem, especially if existing settings get removed from the GUI but stay active in the code. Implementing new edge case features and making them available in the user-preferences.json is totally fine, as long as those features are developed neatly, maintained and don't interfere with the major functionality.

👍

I personally rather focus my efforts on existing features or ones that benefit most users,

That's both obviously the better thing to do and I agree. At the same time, with any feature, there is a product of "number of users x simplicity of implementation x value of the feature (and maintainability, etc like you mentioned above).

I think that exposing settings in text (reading them on startup) may help a minority of users but has a higher score of simplicity and applicability to many things. I think that, conservatively, 70% of my requests I can do myself with text settings/reading user CSS/JS.

@9z0 if you say allow the user to change the defaults in multiple areas, what exactly does this mean?

Options relevant to the functions of sleek and looks without limitation to a particular UI element.

Let the user know (in the file) that these are subject to change. I'd suggest unminifying the json file for ease of use, though!

@9z0
Copy link
Author

9z0 commented Jun 24, 2021

A couple of examples of what I mean by exposing as much as possible of functions of sleek:

  • how often the file is polled for changes.
  • how many todos to show in each lazy loading cycle.

These little things can solve individual-user issues on the long run.

@9z0
Copy link
Author

9z0 commented Jul 17, 2021

Since sleek is moving more and more beyond a bare-bones app, we are increasingly having to choose between customizability and simplicity of use.

A solution like this one is widely used to offer the user a choice while keeping the UI simple and user-friendly.

I added a task list to the first post with what I think is a good foundation to start with the options part (or maybe continue, since sleek already uses these kinds of options 😉).

@ransome1 If you want, I can split this issue into three separate ones.

@9z0 9z0 changed the title Support for manual config files Support for manual config files (Options, CSS, JS) Jul 17, 2021
@github-actions
Copy link

github-actions bot commented Sep 3, 2023

This is an automated response. We acknowledge your report, and we appreciate your engagement. However, as there has been no recent activity in this thread, it has been marked as stale. If you have any further feedback or if the matter is still relevant, please do not hesitate to respond. Otherwise, this thread will be automatically closed in 15 days from now.

@dnngll
Copy link

dnngll commented Sep 13, 2023

Xreference to #99 (comment) to avoid autoclose

@ransome1 ransome1 moved this to Todo in sleek 2.x Sep 15, 2023
@ransome1 ransome1 moved this from Todo to In Progress in sleek 2.x Sep 22, 2023
@ransome1
Copy link
Owner

A custom css file can be used in the latest developer preview, more information here: https://github.com/ransome1/sleek/wiki/Custom-CSS

The config file is not minified in the rewrite if sleek. All currently implemented configurations appear in here.

Regarding JavaScript, I don't see the point. If a user is into heavily customizing an app using JavaScript, it might be a better idea to simply fork sleek.

@github-project-automation github-project-automation bot moved this from In Progress to Done in sleek 2.x Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request help wanted Extra attention is needed
Projects
Status: Done
Development

No branches or pull requests

3 participants