|
My honest opinion? One of the ugliest UIs I have seen in years; it looks like something out of MS-DOS 3. The space for the edit windows is far too small, and the rest of the boxes are just clutter. Unfortunately the rest of your "advantages" do not mean anything without further detail, as the images give no clue as to how they are implemented.
|
|
|
|
|
Quote: My honest opinion? One of the ugliest UIs I have seen in years;
Yes, honest opinion. hehe
This draft even resembles MS-DOS. In game development we call this style: pixel art.
But this image is only a drawing PNG.
Aesthetics is my last concern. Because it does not help to be beautiful if it's disorganized and does not work.
As Steve Jobs said: "Design is how things work".
This observation was relevant:
Quote: The space for the edit windows is far too small
A solution: The "text-box" needs to be expandable and the columns self concealable.
Those who have never used Google Blockly maybe not understand the idea. Here there is more information:
https://github.com/Gurigraphics/plurality
However, this is nothing definitive. And I still do not want to develop a useless prototype.
|
|
|
|
|
Gurigraphics wrote: Aesthetics is my last concern. Then I wonder why you showed those images that do not really mean anything. A more detailed description of what this editor is going to offer may have been a better idea.
|
|
|
|
|
Quote: Then I wonder why you showed those images that do not really mean anything. A more detailed description of what this editor is going to offer may have been a better idea.
Because, fonts, colors, lines, image resolutions are not necessary to understand the idea. But, shapes, structures and positions are required. Because, what the program intends to do, can not be separated from how will do. Since, in the case of an editor, it is precisely the "how" that more interests us. Because, if it is not "practical," it is only "a bad experience" and no matter the outcome.
But I understand what you mean. It was better for me to do an article introducing the idea, the problem, and the reason for it all, before showing any image.
I did not do this because when is necessary to read too much, the "haters" also complain that this is at "a bad experience".
|
|
|
|
|
You might want to look at the work @marc-clifton[^] is doing in this space. Check out his latest articles.
This space for rent
modified 20-Dec-16 6:21am.
|
|
|
|
|
About The Clifton Method?
I'll read it. Thanks
|
|
|
|
|
That's the one. It looks like you're both investigating the same space.
This space for rent
|
|
|
|
|
Okay. Thank's. ^ ^
modified 31-Dec-16 12:52pm.
|
|
|
|
|
When one becomes sufficiently adept at the tools that are already available, one transcends any limitations of the IDE and becomes one with the project's mental model.
Flow.
|
|
|
|
|
Quote: When one becomes sufficiently adept at the tools that are already available, one transcends any limitations of the IDE and becomes one with the project's mental model.
Flow.
Truth. In the world, there are those who accept the things as they are. That prefer to be dragged by a horse cart all life, because they are afraid to get off the ground.
Others... "who see things differently. They're not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can't do is ignore them. Because they change things".
|
|
|
|
|
I hardly consider VS as a "horse cart".
|
|
|
|
|
Quote: I hardly consider VS as a "horse cart".
Well, at least "heavy" as a "horse cart" he is.
Anyway, there is nothing perfect for all cases. But, there is always more suitable or appropriate.
A simple code, Sublime can be more suitable.
For complex debugging, VS can be more appropriate.
Better and worse depends on context.
And so on.
modified 21-Dec-16 19:37pm.
|
|
|
|
|
Yes; I remember when Visual Studio was "Programmer's Workbench".
Don't think I want to go back though.
|
|
|
|
|
|
The paradigms you are holding up are all heavy on the drag-and-drop and other mousing / touching ... perhaps "too heavy" except for beginners.
Just as some prefer XAML / HTML over the designers.
|
|
|
|
|
Gurigraphics wrote: If the files are all exported within a single folder, or hundreds of folders, or the entire file is a single file, this does not matter to the programmer.
Matters to me. Folders provide a way to categorize and thus group code that relates to each other while separating it from other code that doesn't.
Gurigraphics wrote: After exporting the file, what matters is mainly performance. And the performance can not be compromised by our desorganization, habits and addictions when write code.
If someone has a measurable performance problem because of their code organization when developing then my expectation would be that it is a design/architecture problem. It has nothing to do with the underlying persistence mechanism of the code.
Gurigraphics wrote: The idea here is to abolish the organization of files and folders
Rather certain this has been tried multiple times before. Idioms that are successful rapidly take over in the world and continue to be used long after that. Those that do not work do not.
You might want to research past experiments which had larger market attempts to sell them to see why they failed to take off.
|
|
|
|
|
Quote: Matters to me. Folders provide a way to categorize and thus group code that relates to each other while separating it from other code that doesn't.
Currently is that so. But, I think (by practical experience with Stencyl) that if the project is organized inside the editor, that's all that matters for the programmer.
In this other paradigm, continue to use files and folders is how you prefer to have hundreds of files for the objects, lighting, shaders, colors, layers, etc, of a graphic project, rather than a single PSD file.
It is not a matter of agreeing or not. It is a matter of wanting it or not.
I explained the idea better in this text: https://forums.tigsource.com/index.php?topic=59097.0
|
|
|
|
|
Gurigraphics wrote: Currently is that so. But, I think (by practical experience with Stencyl) that if the project is organized inside the editor, that's all that matters for the programmer. That's not true. What matters also includes things like how you keep your code in source control, how easy it is to code review and so on. If you have one big file then reviewing changes is a lot harder than smaller, isolated files that have a single class (or equivalent) inside them. It's certainly easier to use GIT if you have multiple files, rather than one all-encompassing one.
This space for rent
|
|
|
|
|
I'm not sure you've read everything I've written about. Because what you say seems so obvious.
Imagine GIT inside a Multiplayer-Realtime-Editor, and you have an idea of what I say about external file does not import.
|
|
|
|
|
"Folders and files" are a convenient "mental model"; you're confusing them with reality.
The VS solution explorer is a "virtual file system" (which includes "file access" to: TFS; SVN; Git; NuGet) and which scales a lot better than "one big ball of stuff".
It parallels "outlining" as found in Word and Excel; something that "users" are also comfortable and familiar with.
I sometimes have flashes of deep insight into some "new" thing; but they go away after the effects wear off.
|
|
|
|
|
|
That's what I said.
How many enthusiasts have you collected so far?
|
|
|
|
|
Without a prototype I collected only criticism: It's not worth it, the images are MS-DOS, VS is better, nobody needs it.
|
|
|
|
|
If "graphics" is the only thing that is holding you back, there are plenty of FREE tools to make things more "shiny":
Paint; Paint.NET; Gimp; POV-Ray; MS Blend; etc.
|
|
|
|
|
The graphics was just a rough draft.
These days I found ready a part of what I need. And much better than I could do.
jQquery sortable lists[^]
|
|
|
|