IssuesForProfessionals
From REALbasicWiki
Contents |
[edit] Catering for Professionals - Who and Why
The idea behind this page is to create a simple list of the issues in current or recent RB versions that most affect Professional Users either current or prospective users. The selfish goal is to build up sufficient justification for some of these issues to be prioritised. As of Feb 2008, RS are showing a distinct trend of improving focus, deprecating parts of the language and framework that either carry a heavy engineering burden (bindings) or seem of low relevance to most users (RB3D).
Where possible, please point to issues in their tracking system and, most of all, make sure you have a simple justification for why the issue is of particular relevance to a professional user. To help with this focus, please think about people using RB in team development, building up substantial bodies of code or otherwise making heavy use of the language. When in doubt, consider an audience migrating from Java, VB.Net, C# or C++ languages and frameworks.
[edit] Working in Teams
The VCP Version Control Format was a welcome introduction of a pure text format resulting in reasonable diff and merge behaviour with version-control systems like svn and cvs. However, instabilities and limitations in the format mean that the current (Feb 2008) use by professionals and teams is with a high degree of caution. In particular, project corruption because of items being written partially or overwritten is very worrying.
- Making the VCP textual format more robust so it can be used for version controlled source shared between multiple projects:
- A way to use shared VCP items between multiple projects
- Save as Version Control format kills external encrypted items with subclassing
- Timers gain an extra property on the second open-and-save of the project
- Using namespace with controls is not restored from VCP format
- Console and desktop flags on methods are not saved in version control project
- Unable to add comment to a property declaration when using version control format
- Export to version control format is inconsistent (when try to use to export just part of a project
- When saving in CVS format, the modification date of the ".rbres" file are always changed - The file is constantly changing because it is reconstructed every time you save. In the current design, the order of the items is not guaranteed, so it needs to be rewritten every time. Currently, resource items are unable to track their changes, which throws another wrinkle in the problem.
- Version Control Project format - rbres file is created with the wrong name
- bvcp doesn't store the compatiblity "flags (for desktop-only or console-only module contents)
[edit] Documentation
- Ensure that documentation is up to date when released and things can be found in logical places.
[edit] Dense Data Entry Forms
There are certain characteristics of data entry forms in applications used heavily by people who either need to get to a lot of information quickly or need to enter data with minimal keying. Many of the in-house applications developed with REALbasic would, I expect, fall into this category. The in-house developer market is a professional market, quite likely to lead to multiple sales for a single organisation and some of their GUI needs may fly against conventional HI guidelines from Apple or the expectations of people who've never developed or supported such applications.
Based on recent mailing list threads, areas of particular concern for such users are:
[edit] Nested Tab or PagePanels within Panels
Nested page or tab panels are a very useful and powerful technique when you have related content people want readily available. It works particularly well when their style is "modal" and they will be looking at a particular aspect of data for a prolonged period but might want to flick across to the related content.
[edit] Tab Order not controlled by GUI Nesting Order
This may sound very non-intuitive but had a bunch of people chiming in with "me-toos".
Tim Jones said: The layout on screen matches a paper form's layout, but sometimes I skip pre-filled fields as it's only necessary to change the pre-filled contents once in a blue moon.
Karen said: For example a data entry from may have fields that are rarely changed (autofilled or empty 99% ofthe time) but needs to be acessable/editable but are logically grouped information wise with certain other info that is always entered. In a form with a lot of fields you don't necessarily want to force the operator to have tab through them to fill out the the form,so you put them at the end accessable by keyboard and mouse.
[edit] Other Control Issues
Not just the domain of the in-house developer but coming from a wider range of discussions on the mailing list:
[edit] Better Grid or Listbox
I (Andy Dent) am quite happy for third-party controls to carry some of the weight of providing powerful grids. Grids by themselves are a substantial programming task and in the VB and MFC communities I'm familiar with multiple add-on controls filling this need.
Michael Diehr said Listboxes should allow embedding of all control types as real subclassable objects, e.g. I should be able to subclass a combobox, and set the listbox.celtype to use this object for editing.
Norman Palardy said:
- no need to load the list with 100% of the data to deal with large numbers of rows (Einhugur's data grid behaves like this)
- the ability to embed any kind of control in a cell
- the ability to have varying row heights
- ability to select a column
[edit] Linux Support
As mentioned above, I think the in-house developer market is an important one for RS and I also I think likely to grow with the growth of Linux for desktops. Indeed, you could argue that RB being perceived as a professional VB replacement may well be the clinching argument for some organisations to move internal apps to Linux desktops.
