Home » RADICORE » RADICORE Suggestions » Development Diary (markcarranza) (Experiences with Radicore)
| Re: Development Diary (markcarranza) [message #3222 is a reply to message #3214] |
Wed, 19 December 2012 16:52   |
AJM
Messages: 2371
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
While I welcome comments and criticisms, I feel that some of your points do not have enough substance for me to work with. Let me try to address your negative points one by one:
1) user interface not good for client services, more for programmer types
Can you define "not good"? What changes would you make? If it is fonts, colours and positioning that you don't like then you can easily add your own CSS files, as explained in The use of Cascading Style Sheets within Radicore
Radicore was designed to aid in the development of back end administrative applications which are used by members of staff, and not front end websites which are used by casual visitors. Having functional screens which give fast access to the organisation's data has a higher priority than sexy screens full of gimmicks and fancy images. I have written applications with Radicore which are regularly used by non-programmers, and they do not have any difficulty using the screens.
2) likely need to edit core files, Radicore upgrades would need programmer interaction
Radicore is not meant to be used by non-programmers. It is not an end-user application in its own right; it is a tool which allows programmers to develop their own applications more rapidly, with less effort, and with more features than other frameworks.
3) special security needs requires audit of source and upgrade code
What special security needs? Would these needs require the same action in other frameworks?
4) possible intimidating learning curve for future maintenance PHP developers
There will be some sort of learning curve with whatever framework you choose. You should also consider the fact that the quicker that something is to learn then the fewer facilities it has to offer. Radicore is a bit like PHP itself easy to learn for simple tasks by providing default behaviour which covers all the basics, yet flexible enough to allow virtually all defaults to be overridden or replaced with you own code which you can customise to your heart's content.
5) single person company/support
Some people would see this is as a benefit as you don't have a group of different people with different opinions trying to push the product in different directions. Have you ever heard the saying "A camel is a horse designed by a committee".
6) no unit tests, test suite, automated tests
The cost of producing unit tests substantially outweighs the benefits. I'd rather spend my time producing software that works than writing a second piece of software to prove that the first piece of software works.
7) no needed HTML reporting, only PDF
I don't understand this point. An HTML report is just an HTML document, just as a web page is an HTML document. I have regularly produced "reports" which are actually web pages instead of PDF documents, and I usually include the ability to export all the data to a CSV file so that it can be manipulated in a spreadsheet. What sort of reporting capabilities would you like to see?
8. The UI is tremendously too busy, not the simplest possible for the user community I have to support. I have to radically minimize the choices, degrees of freedom for the user. Make it perfectly clear, with the minimum of choices on screen at any one time.
Define "too busy". Every component in the screen has useful functionality, so what functionality would you remove? You also have to bear in mind that when you implement your own application using Radicore that it has whatever menu buttons and navigation buttons that *YOU* decide to implement, and each screen contains whatever data you choose in whatever place you choose (within reason) using whatever HTML control you choose. The subsystems which are built into the Radicore framework menu, data dictionary, audit and workflow work the way they work and look the way they look, but any additional subsystem which *YOU* build can be customised by you to look and behave the way *YOU* want.
If you really want to change the way the standard screens look you can always try replacing the default CSS files with your own customised versions.
If you want to use JavaScript then go ahead. I do not use any in the Radicore framework itself, but I have built in the ability for you to add in whatever JavaScript you choose. Take a look at RADICORE for PHP - Inserting optional JavaScript
Comments on the "List Subsystem" screen:
- There are two search buttons
One activates a separate screen based on the SEARCH pattern (see http://www.tonymarston.net/php-mysql/dialog-types.html#searc h) while the other is part of the Quick Search bar (see http://www.tonymarston.net/php-mysql/dialog-types.html#title -bar) While they both allow search criteria to be entered they do it in different ways, one quick, one slow.
- search should be named 'Find' or 'Query'
I have known this type of screen as a "search" screen for several decades, and I see no point in changing it.
- In column search, when column dropdown is blank, search fails and typed-in search term unexpectedly disappears. Blank column dropdown is useless and broken. Show no blank: first or best column in dropdown. Or change blank column dropdown search to query all text fields.
By "column search" I assume you mean the Quick Search bar, which works exactly as documented and does not need to be changed.
- if 10 or less records, hide paging top (show...) and bottom
Why? Nobody else has suggested such a change, so it must be very unimportant.
- List column heading 'Select' could be link/toggle select all/select none. If all selected, then 'None' otherwise 'All'. JavaScript required.
To say that this should act as a toggle between select all and select none implies that the selection is limited to either all or none, which is incorrect. It is possible to select any number of entries manually, so what would the next choice be? It could be one or the other, so which would I choose? There is room on the screen for both options, so I will keep both.
- not sure what 'locked' check box does
Take a look in http://www.tonymarston.net/php-mysql/dialog-types.html#navig ation-bar
- list column heading 'Count' clearer as 'Tasks'
OK. I'll change that to be consistent with other screens in the system.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
Current Time: Wed Nov 27 15:27:03 EST 2024
Total time taken to generate the page: 0.01158 seconds
|
Radicore Forum
Search
Help
Members
Register
Login
Home
