minor HCI usability wishes
I would like the left sections in winbox to be in some sort of order. They aren't in any really. Maybe alphabetical. It would make use a little easier and quicker. Also I think a reorganizing of what's in system and what's in tools would be good. telnet is on one, mac-telnet is on the other, they are somewhat similar in purpose -why not in the same menu? Ssh client is more of a tool than a system setting. Thanks!
!
The two things I'd like to see is the items with the longest dropdown window at the top of the list - for example depending on screen settings - you click on system and the list of system options is off the bottom of the screen - you mean theres ntp options somewhere at the bottom - and secondly to have the telnet function available from the root in a similar fashion to the simple ping. rather than in system. With routing
problems etc. the first thing I want to do having reach the next in the chain
problems etc. the first thing I want to do having reach the next in the chain
Agreed, along with ssh.and secondly to have the telnet function available from the root in a similar fashion to the simple ping. rather than in system. With routing
problems etc. the first thing I want to do having reach the next in the chain
/telnet w.x.y.z, is more natural then /sys tel w.x.y.z.
Could easily shave 1-2 grumbles per troubleshooting session, and save 5min explination time per tech.
--Eric
Yeah, or maybe for shutdown a second "Are you REALLY sure you want to shut down your router that is an 80km round trip and hours of downtime away?"I would like to split shutdown and reboot buttons by other. Sometimes we want quickly reboot the router, but we click not reboot, but whutdown button
Everytime I pull something from that area of the menu I cringe...
One more usability suggestion..
On most linux and many unix systems, administrative user (root) has a different prompt. What the prompt is, is of course based on the shell, not the OS.
As you see, regular users get a greater than prompt, root gets a number symbol.
In MT, the administrative user gets the greater than prompt, just like the less privelaged user. It would nice if the prompt differed for the types of user, just like in linux shells.
On most linux and many unix systems, administrative user (root) has a different prompt. What the prompt is, is of course based on the shell, not the OS.
As you see, regular users get a greater than prompt, root gets a number symbol.
Code: Select all
jp@mexican:~> su -
Password:
===========================================================
Warning - All Access is logged.
Unauthorized access will be prosecuted.
===========================================================
mexican:~ #
Code: Select all
[nobody@mis south] >
[admin@mis south] >
For me, I'd like to be able to make the winbox window smaller. Right now, you can't make it any smaller than the list of buttons on the menu. If I need to see 2 or 3 winbox screens at once, it is difficult because I cannot make them fit.
Also, I'd like a button at the top that would arrange all open windows. You can do it by "tiling" the windows (all would be fitted to current winbox area), or "cascading" (that's the windows word for it).
Also, I'd like a button at the top that would arrange all open windows. You can do it by "tiling" the windows (all would be fitted to current winbox area), or "cascading" (that's the windows word for it).
This is not very clearly stated. The "windows" I'd like to be able to "tile" or "cascade" are the open applets in the winbox.Also, I'd like a button at the top that would arrange all open windows. You can do it by "tiling" the windows (all would be fitted to current winbox area), or "cascading" (that's the windows word for it).
with regard to software packaging to make it more userfriendly...
Just plain routerboard package I presume is rb230, whereas the routeros-rb500 is for 5xx/1xx routerboards. Perhaps routerboard-xxx.npk should be renamed routeros-rb230-xxx.npk to be properly descriptive. If there were a way to make the naming include the rb1xx for the 5xx package that would be helpful too.
Just plain routerboard package I presume is rb230, whereas the routeros-rb500 is for 5xx/1xx routerboards. Perhaps routerboard-xxx.npk should be renamed routeros-rb230-xxx.npk to be properly descriptive. If there were a way to make the naming include the rb1xx for the 5xx package that would be helpful too.
While we're at it, in Winbox, it would be nice if there were a scale on the traffic graphs.
If you want to know what the bandwidth peaks are, you have to compare it to the most recent traffic, estimate or calculate a factor, multiply it by the current bandwidth, which had probably changed by the time you did the math. If there were a scale, even a changing scale, it would be much easier to see a traffic spike and follow the horizontal rule to the a y-axis scale. Time scale on the X-axis would be good too.
I use mrtg for long term traffic graphing, but the traffic graphs like above are very nice for more detailed analysis.
If you want to know what the bandwidth peaks are, you have to compare it to the most recent traffic, estimate or calculate a factor, multiply it by the current bandwidth, which had probably changed by the time you did the math. If there were a scale, even a changing scale, it would be much easier to see a traffic spike and follow the horizontal rule to the a y-axis scale. Time scale on the X-axis would be good too.
I use mrtg for long term traffic graphing, but the traffic graphs like above are very nice for more detailed analysis.
Here are some suggestions;
* put back neighbor discovery on bridge members. it's -really- annoying
when you try to find out which interface those discovery packets came
in on.
* remove 'shutdown' from winbox but keep it in terminal.
- How often do you do it anyway?
* packets/second graphs!
- perhaps as a transparent overlay for bytes/second?
* macros or functions in script context
* ability to do "monitor do={" without them automatically being assumed to "once"
* better error handling in scripts.
- line and character hint when / importing would be nice
* packet/second trigger for traffic-monitor.
- how many tiny packets can you send at the rate of 2 mbit / sec ?
* ability to select connection-tracking pr rule
* ability to run a / interface pppoe-server server monitor in loop
which triggers every time someone logs in or out
* more informative log messages for ppp(oe)
* error and informational statistics on ethernet and wlan interface
routeros probably gets blamed for alot of faulty wiring, which is
easily debugged using statistics.
* wireless beacon interval setting
- 10 times a second is wasteful for fixed wireless.
- doubling the rate because you add a virtual ap is twice so.
* ability to set mtu to higher than 1500 and let kernel decide wether it's possible or not. it's possible for several common 10/100 mbit cards.
* ability to do
- "/ tool graphing queue find"
- "/ tool graphing interface find"
- "/ tool graphing resource find"
* ability to adjust max resulting eoip packet size to deal with smaller mtus
* stop setting df flag on non-tcp packets (it's breaking standards and functionality.)
* put back neighbor discovery on bridge members. it's -really- annoying
when you try to find out which interface those discovery packets came
in on.
* remove 'shutdown' from winbox but keep it in terminal.
- How often do you do it anyway?
* packets/second graphs!
- perhaps as a transparent overlay for bytes/second?
* macros or functions in script context
* ability to do "monitor do={" without them automatically being assumed to "once"
* better error handling in scripts.
- line and character hint when / importing would be nice
* packet/second trigger for traffic-monitor.
- how many tiny packets can you send at the rate of 2 mbit / sec ?
* ability to select connection-tracking pr rule
* ability to run a / interface pppoe-server server monitor in loop
which triggers every time someone logs in or out
* more informative log messages for ppp(oe)
* error and informational statistics on ethernet and wlan interface
routeros probably gets blamed for alot of faulty wiring, which is
easily debugged using statistics.
* wireless beacon interval setting
- 10 times a second is wasteful for fixed wireless.
- doubling the rate because you add a virtual ap is twice so.
* ability to set mtu to higher than 1500 and let kernel decide wether it's possible or not. it's possible for several common 10/100 mbit cards.
* ability to do
- "/ tool graphing queue find"
- "/ tool graphing interface find"
- "/ tool graphing resource find"
* ability to adjust max resulting eoip packet size to deal with smaller mtus
* stop setting df flag on non-tcp packets (it's breaking standards and functionality.)
There seem to be print options that don't work. This is with 2.9.25
Also in winbox, in many different parts of winbox, I noticed a little disabled text at the bottom of the window. I had to disable and renable something to figure out what it meant. Greyed out disabled means enabled - sort of a double negative, which is rarely helpful. It would be better to either only show disabled text when it's disabled, or enabled instead of disabled.
Either way it's redundant, since a disable action button appears when the item is enabled, and vice versa for an an enable button.
Code: Select all
[admin@knoxcourthouse] ip firewall mangle> print stats
invalid value for argument filter
[admin@knoxcourthouse] ip firewall mangle> print detail
invalid value for argument filter
[admin@knoxcourthouse] ip firewall mangle> print ?
print values of item properties in different formats.
<filter> --
without-paging --
count-only --
interval --
append --
file --
chain -- Chains through which packets are traversing
action -- Action to undertake if the packet matches the rule
jump-target -- Name of the target chain, if the action=jump is used
address-list -- Address list in which marked address put
new-packet-mark -- Specify the new value of the packet mark to be used in conjunction with action=mark-packet
new-connection-mark -- Specify the new value of the connection mark to be used in conjunction with action=mark-connection
new-routing-mark -- Specify the new value of the routing mark used in conjunction with action=mark-routing
new-tos -- Specify TOS value to be used in conjunction with action=change-tos
from -- item numbers
stats --
value-list --
terse --
detail --
[admin@knoxcourthouse] ip firewall mangle>
Either way it's redundant, since a disable action button appears when the item is enabled, and vice versa for an an enable button.
I have a great idea for the shutdown and reboot buttons in winbox.
Instead of its current format:
Do something like this:
Where 'yes' and 'no' are radio buttons, and no is selected by default.
This way, the function they're working with is in all caps (just so it stands out) and then if the user accidently clicks the button or presses enter, the action is set to 'no' by default.
Instead of its current format:
Code: Select all
Do you want to shutdown?
[Yes] [No]Code: Select all
Do you want to SHUTDOWN?
( ) yes
(*) no
[Continue]This way, the function they're working with is in all caps (just so it stands out) and then if the user accidently clicks the button or presses enter, the action is set to 'no' by default.
normis, I understand where you're coming from, but.. there's a big difference between typing out the shutdown command and clicking a button in a GUI. Adding a bit of security to the GUI, such as this, could not hurt, could it?
However, I guess I could see someone quickly selecting 'yes' and clicking 'continue'. But surely not, if the function name stood out (ie, "SHUTDOWN").
Any thoughts?
However, I guess I could see someone quickly selecting 'yes' and clicking 'continue'. But surely not, if the function name stood out (ie, "SHUTDOWN").
Any thoughts?
maybe when askiking if you realy want to shut down and answers are - YES|NO set to SHUTDOWN|NO
or even make it changable so person can set to "CLIMB 100M tower to startit"|no
and if person sets this feature to NO|NO he actualy cannot shutdown this router
EDIT:
actauly there is even better and safer idea - if you want to reset or shutdown router - you have to enter password to do that, that ways - those FAST WRITERS that cannot read will be forced to stop, atleast they should stop. i hope.
or even make it changable so person can set to "CLIMB 100M tower to startit"|no
and if person sets this feature to NO|NO he actualy cannot shutdown this router
EDIT:
actauly there is even better and safer idea - if you want to reset or shutdown router - you have to enter password to do that, that ways - those FAST WRITERS that cannot read will be forced to stop, atleast they should stop. i hope.
Winbox loader wishes:
* In the search button - If an IP is displayed and selected, let the IP transfer to the "Connect To:" box instead of the MAC.
* Remember "Load Previous Session" de-selection. Won't stay off!
* Changelog for WinBox.
* Changelog for WinBox. Or at least a note somewhere that the version has changed.
* In the search button - If an IP is displayed and selected, let the IP transfer to the "Connect To:" box instead of the MAC.
* Remember "Load Previous Session" de-selection. Won't stay off!
* Changelog for WinBox.
* Changelog for WinBox. Or at least a note somewhere that the version has changed.