[Nae Khar]

A more user friendly and graphical interface, to expand its user base to everyone with an interest in data analysis, and not only the small subset interested in programming

[Nae Khar]

Sometimes you just want to drag a column, without a paragraph of code

[Sven-Kristjan Bormann]

What do you mean by "dragging a column"? What do you want to achieve/do?

[Nae Khar]

@Sven-Kristjan Bormann
This: https://www.stata.com/manuals13/dorder.pdf

[William Lisowski]

Nae Khar - From Stata's menus, the "Data > Data Utilities > Change order of variables" selection provides a menu-driven front end to the order command. Not as convenient as dragging a column, but a perhaps easier than typing commands.

[Nae Khar]

@William Lisowski

Thanks for your response. I am aware of that. I mean in general. Make it more intuitive. Create a “discoverable” interface that does not require too much digging to get the simplest things done. The use of analytics has spread to a wide range of people, not only professors and researchers.

This makes it comfortable for academics (but not me, because I am way to intellectual to admit a need for this), and easier to teach and engage undergrads.

A little bit of user-friendliness never hurt anyone.

[Bruce Weaver]

Hello Nae Khar. I think most members of this forum appreciate user-friendliness. But for any serious data analysis, I think that code is essential for reproducibility and documentation of exactly what has been done. If we teach students that it is essential to thoroughly document other aspects of their methodology when carrying out a study, why would we not do the same for statistical analysis?

Although he was talking about SPSS rather than Stata, I've always liked Raynald Levesque's comments on the need for syntax on this page:

• http://www.spsstools.net/en/syntax/learning-syntax/

I also like very much Raynald's statement about the main purpose of a GUI:

As far as I am concerned, the main purpose of the GUI is to facilitate writing syntax!

Cheers,
Bruce

[wbuchanan]

Nae Khar
Are you advocating for a user interface that is more similar to something you might find in Tableau, PowerBI, or other business intelligence related software? Just trying to get a better idea/understanding about the scope of the use case that you have in mind.

[jerome falken]

In respect to #256..#263:

I think the user interface is extremely usable, I wish the "Data Editor" could cycle through different frames, I think tableau/powerbi/etc. are different set of tools for a different category of users, and wouldn't want my favorite statistical software to look like powerpoint.

I like that Stata's UI is extremely responsive even on older hardware, unlike Mathematica for instance which is overly complex and very slow; I think it's also good to add that Stata's UI is modifiable (through the "User" menu). I really also appreciate the inline help and readily available pdf documentation if you want to dig a bit deeper into a specific functionality.

This is my personal opinion, Stata has a very strong user base with very knowledgeable people, I've seen too many (other) products losing their strong core user base because they decided to adopt a flashy UI (i.e. electronjs , google chrome framework, nodejs, etc.)

[wbuchanan]

jerome falken

I’m a bit confused about some of the UI references that you made - node.js in particular. It isn’t necessarily a result of using any specific framework or server side technology (like node.js) that makes a UI do anything in particular, but comes down to how those tools are used. I would argue that most JavaScript based UI frameworks would actually provide the greatest responsiveness since it is a core function of all modern UI frameworks to be responsive to varying screen dimensions.

That aside, while it is possible for users to develop their own dialog boxes/menus, the current framework for doing that in Stata is a bit challenging to work in. Fixed screen dimensions can make it challenging (if not impractical) to create dialogs that are truly responsive for end users while also providing a reasonable user experience. Thankfully the staff at StataCorp have a lot of experience with that system and have found patterns that make the UI design work well for their commands within those constraints.

[Nick Cox]

On user-friendly see also https://www.youtube.com/watch?v=7mQD_Wd6Ajo

[Sergiy Radyakin]

If possible, I would like to see the doeditor dockable in the main Stata window as an option. This would definitely help the users of large [wide] monitors to configure and preserve the configuration of output + code in the same layout. The current mode of showing the doeditor in a separate process window is usable, and best for multiple monitors setup. But for a single wide monitor a dockable doeditor would be preferred, imho.

If possible, I would also like to see another kind of output window included. Conceptually a "document" view - which could be a viewer for common document types [html, pdf, markdown, ?latex?] which could be generated from within Stata, with perhaps some minimal control (add tabs, switch tabs, load a list of documents, scroll to beginning or end of the document, etc). The key advantage is to be able to relatively easily view the generated output combining textual, tabular and graphical information relying on built-in/cross-platform functionality, rather than on presence of any other tools/software on the user's machine.

Or the current viewer can be extended to include those file types alongside the text, smcl, and sthelp files.

Thank you. Sergiy.

[Leonardo Guizzetti]

Sergiy, as a workaround to docking the do editor, have you tried tiling the windows? I have done this successfully and easily on Windows and some Linux distributions using simple keyboard shortcuts and on a single widescreen monitor. In Windows for example, use window key + direction arrow, and when two windows are arranged into a left and right pane, you can resize both of them synchronously by resizing the shared border so you can allocate more or less space to the do editor.

[Sergiy Radyakin]

Dear Leonardo, Colleagues,

yes, certainly tried that. It is not the same. Tiled windows are independent. So if you switch to e.g. Word or Outlook - it covers both. Then you need to go back to Stata. You seek for Stata window to bring it on top, then you start seeking for the corresponding do-editor to bring that on top of word as well. If you mis-switch accidentally to 3rd program - start all over again. Or (as is common with me) open some 6-12 Stata sessions with each of them having a separate (one or more) do-editors. There is no way to even understand in which Stata window to seek for the output of it running. This is related to my other wish to have a button/hotkey to bring the Stata window from the do-editor. My workflow is :

• correct the do file;
• press Ctrl+S to save;
• press Ctrl+D to execute;
• press Ctrl+O to switch to the corresponding Stata window to see the output.

Since the last combination doesn't exist, instead I have to seek among the tons of windows which one corresponds to what. Annoying and frustrating. (Not as frustrating as in the good old times when I used to send do-files for remote execution and get the error back a week later, but the demands have risen since then )

After that of course one would wish to jump back to the do editor. I admit this is a bit more complicated, since there may be multiple do editors for the same Stata session (though only 1 session for each editor!!), but jumping to the last that was active is the most reasonable behavior (imho), so that Ctrl+O can switch back and force between the code and the output that it produces.

On my screen now:

Another bit that aggravates the issue is that the headers are named non-traditionally:

- common: "Document1 - Microsoft Word", "Google.com - Internet Explorer", "Picture1.png - Paint", "Untitled - Notepad"
- Stata: "Do-file Editor - ...", "Graph - D...", "Viewer - help tw..."

so that the most valuable part, the specification of the document I am working with, Stata places at the end, making it disappear in abbreviation with multiple windows competing for space.

I am not sure if there are rules for sorting the windows in this list, e.g. whether the windows for the same session of Stata are grouped together, but based on the simple trials they are not, and perhaps they are sorted chronologically, (type help something in the first session window, and it will appear after the last session window), or based on the next available PID or something else.

And if you think that it's my own problem - imagine being called by a colleague (with a similar mess on the screen) for troubleshooting something (happened to me all the time in those days when the office work was possible). It's a nightmare. You have no idea about how many windows are open, to which sessions they are attached, which program generated which output, and what will be lost if I attempt to close something. The number of queries on this list about how to recover the do-file overwritten with data or data file overwritten by code is a testament to this confusion.

Oh, yeah, and try to disconnect one of those 3 monitors connected currently. You'll have more chances of winning on a zero in Las Vegas, than finding which window will jump into which position.

There is a need for some meaningful higher-level management actions, more then just maximizing the current window.

• show the list of all windows associated with the current session (data, code, graphs, etc) with the status saved/not saved, named/not named, and a possibility to switch there;
• sort windows grouping by session;
• bring forward all windows associated with current session;
• minimize everything else except related to the current session.
• tile or cascade the current session windows.
• circle-navigate between the windows of the current session.
• join all the tabs of multiple (two specific or all open) do-editors into one.
• etc, etc, etc.

There are four different versions of execute/do/run in the do-editor menu, but not a single one of them allows to do-and-switch-to-output, which imho is the most logical on a single-screen machine.

Lots of more thoughts on this, but not much time. "Close all viewers" was added relatively recently, I believe, so perhaps someone is thinking about/working on these issues (no hotkey for that, sigh). It was earlier confirmed that code folding is coming soon. Hope more could be done for window management too. Visual Studio, imho, is also not perfect in managing the windows, though it has a much more diverse nomenclature. Yet somehow I've managed to find a comfortable arrangement of code on one screen and everything else docked in another.

Users on Windows platform may refer to https://www.windowscentral.com/best-...oard-shortcuts for a comprehensive list of keyboard shortcuts in modern Windows (if you think you know there is just Ctrl+C and Ctrl+V, just check...).

🚩 None of the above should be interpreted as critique of Stata product. It is absolutely wonderful and I love it. It is just that the mess is stemming from the complexity of the tasks it handles. If you are a beginner wishing to load your data, run a regression and plot the residuals, don't worry at all about any of those issues, you will likely not encounter them.

Best, Sergiy

[FernandoRios]

I think this comes once in a while but,
I would really wish on Stata 17, Stata graphic files (*.gph) could be created so they are backward compatible, or at least give the option to save them so older versions of Stata can access them.