Home » RADICORE » RADICORE Suggestions » Development Diary (markcarranza) (Experiences with Radicore)
| Re: Development Diary (markcarranza) [message #3230 is a reply to message #3224] |
Fri, 21 December 2012 03:16   |
AJM
Messages: 2355
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
1) If you want your new application to have the same look and feel as your old application then I fear that Radicore will not be the right framework for you. Radicore is for building web-based applications and therefore uses HTML screens, so it will never have the same look and feel as a legacy desktop application. There may be certain things which you can change with javascript, but that depends on your skills with javascript. The purpose of Radicore is to provide functional screens as quickly as possible with as many facilities as possible. You can then customise the screens to your heart's content. But if you spend 5 minutes building a basic screen with Radicore followed by 5 weeks of customisations then I fear that the benefits of Radicore will be wasted.
2) Your comments on "List Task (Process)"
a. Too many buttons. Response: There are 14 navigation buttons in that particular screen for the simple reason that there are that many child screens to which it is possible to navigate. Different screens will have different numbers of navigation buttons.
b. Way too busy visually, hard to read, harder to find correct button. Response: It gets easier with time.
c. Buttons should be grouped visually by category of task. Response: You can easily change the order in which the buttons are displayed refer to the Sort Sequence field in Update Navigation Button
d. Button locations should not change when screen re-sizes. Response: I'm afraid you do not understand how HTML works. Each HTML document is automatically resized when the dimensions of the browser window change. This may mean that some controls are resized or even repositioned. This is a "feature" of HTML, and there is very little you can do to change it.
e. User-setting-optional tool tips should concisely describe function of each button. Response: It may be possible to provide tool tips by using the HTML "title" option on input controls, but whether they work or not will depend on the browser which you are using. I will add the task's description as a "title" attribute in the next release.
f. Number terms used across Radicore like (1)(2)(3) in 'Navigation(1)/Navigation(2)/...', or in 'List1/List2/...' should be replaced by semantic terms or abbreviations. Response: There are 3 buttons labelled "Navigation Button" in "List Task (Process)" because there are 3 ways in which the MNU_NAV_BUTTON table can be viewed and maintained using different transaction patterns. Button labels should not be too long otherwise they will take up too much room on the screen. Besides, with the addition of tool-tips longer labels should not be necessary.
g. Buttons always present like standard: read, update, delete should be in their own standard area, visually separated from custom options, as close to data as possible. Response: Different people seem to have different opinions as to which buttons should be where depending on how they are classified, and even then they cannot agree on what those classifications should be. In my opinion having different areas for different classes of buttons would take up too much space on the screen. The only compromise I have agreed to implement is to split navigation buttons into two types those on the top line do not require any pre-selection of rows in the data area while those in the bottom line do.
3) Likely need to edit core files, Radicore upgrades would need programmer interaction. Response: I repeat, Radicore is a tool for developers, not end users. If an upgrade to Radicore is released there is no need to upgrade an existing application unless it fixes a bug or it adds functionality that is required. In any case, it will be up to the developer to implement and test the upgrade on a development system before it is applied to the live system. It has been my experience that if an organisation without its own IT department hires a third party to develop an application for them then the wisest move is to take out a support contract with that third party for ongoing maintenance. Not having a support contract and then trying to hire other contractors on an ad-hoc basis to deal with urgent issues sounds like an option that is fraught with problems they would not know the application and would require a learning curve which would take time and would therefore be expensive.
4) With Radicore I might, for example, need to change user_IDs from VARCHAR to INT. Response: I can think of no sensible reason why you should ever want to do such a thing. In would be an enormous effort for no tangible benefit.
5) I do not know, but prudence tells me to anticipate need to significantly change many core Radicore files. Response: If you think that you may want to change any core files within Radicore then Radicore is probably not the right tool for you. Besides, if you change any core files I cannot be held responsible for the consequences and I will not be able to offer any support.
6) Upgrading to a new Radicore version, under this scenario, would require significant effort and an above-average PHP coder. Response: You have previously stated that you are in the process of writing a critical medical application that requires strict compliance with Federal regulations, so the idea that you would contemplate using anything other than above-average programmers I find rather surprising.
7) This is a medical-services client, the new software will contain highly confidential patient information. Response: The contents of any application database you create, and any code which you create to deal with that data will be your responsibility as your application indeed *ANY* application which has been built using Radicore is completely unknown to me and outside of my control. If you or your client are worried about the security capabilities of Radicore all I can do is point you to The Radicore Security Model
8 ) Imagine changing all existing Radicore PDFs to web pages, with (optional) print button and print css. Response: You don't change PDF documents to web pages. A web application contains HTML documents, and HTML documents cannot be used to create large reports which can be sent to a printer. The client can use the browser's "print" button to print what is currently being displayed in the browser window, but that's not the same thing. With Radicore you can produce web pages containing whatever information you like. You can extract that data to a CSV file, but you can't send it to a printer which is attached to the client device.
9) I'd love to see a system allowing user-created queries and reports. Response: Then what you want is a customisable report generator which you can obtain from a third party and which connects directly to the database, thus bypassing any "limitations" within Radicore.
10) Haven't installed example systems yet, it would be great if one showed significantly different look and feel. Response: You'll be disappointed then, as all the example systems share the same look and feel. This is because they all share the same transaction patterns, the same XSL stylesheets, and the same CSS files. It is this sharing of standard and reusable components which allows Radicore to be a Rapid Application Development toolkit. If you want everything to be different and unique you can kiss goodbye to sharing common components and kiss goodbye to rapid application development.
11) User Interface. Response: If your client is used to a Windows GUI in a legacy application then they will disappointed that a modern web application is not exactly the same. A web application uses HTML documents for its screens, and HTML (with CSS) can look different in different web browsers. If your clients are unwilling or unable to accept the differences in a web application I can only suggest that you stick with a desktop application.
12) Quick Search bar. Response: I have changed the button text from plain "Search" to "Quick Search" to differentiate it from the other "Search" button.
13) "Locked" checkbox. Response: Like yourself I thought that the default for this control should be ON, but my major client disagreed and insisted that it be turned OFF. It is impossible to please everybody all of the time, so I am afraid that somebody will always end up being disappointed that they cannot have their own way with everything.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
Current Time: Wed Jul 31 12:01:17 EDT 2024
Total time taken to generate the page: 0.01290 seconds
|
Radicore Forum
Search
Help
Members
Register
Login
Home
