-
-
Notifications
You must be signed in to change notification settings - Fork 115
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
Comments
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 I think this will benefit the advanced user while being easy enough for @ransome1 to add. |
@9z0 if you say |
What did you see it as? :D
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:
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. |
👍
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.
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! |
A couple of examples of what I mean by exposing as much as possible of functions of sleek:
These little things can solve individual-user issues on the long run. |
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. |
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. |
Xreference to #99 (comment) to avoid autoclose |
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. |
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:
userchrome.css
(for customizing the app UI) anduserstyle.css
(for customizing MD rendering). See here.It comes down to just reading a user-filled CSS file/JS file and running them on startup.
Tasklist:
Options
user-preferences.json
so that it can be easily edited. Alternatively, support a simple format, likeini
along with/instead of the json file.CSS
JavaScript
The text was updated successfully, but these errors were encountered: