|
I haven't done any push notification work but that maybe a better way to go.
"You get that on the big jobs."
|
|
|
|
|
Hi,
I'll make it short and clear (I hope).
We have two teams developping our product, the R&D and the 'Integrators'.
I'm not sure how the Integrators are called in english, maybe TPAM (Third Party Application Maintenance), anyway, let's say that Integrators = People working on the base product, adding or changing functionalities for a specific customer. And the R&D team beeing in charge of doing what's common to all of them (the customers).
The R&D team is in charge of developping functionalities available to all our customers, and the other team only does specific developments for specific customers.
The problem we're dealing with is that both teams may develop on the same web pages, controls, business logic etc. What happens is that our Release Manager deploys what the R&D team has been doing in some sort of common workspace, and he can't be aware of what's from one team or another, so a lot of times, the Integrators work is lost and our release manager spends hours finding the 'lost changesets' and re applying those modifications.
We're need to solve this problem and what we came with far now is to develop some sort of API exposing all the common asp.net events (page_init, load, render, etc.), we also should fire events when entering/exiting BL and DAL functions allowing the Integrators to develop 'manually', maybe injecting some asp.net code into the existing pages, also some code behind, javascript, etc. I'm not really sure if this is a reasonable idea or not, we've just been thinking for like 10 minutes and I wondered what did you recon in this kind of situations.
This is just an idea, because they may develop everywhere... Web, BL, DAL and Database (we have a project for that).
Just to be clear, we're developing a product, I'm not sure how it's technically called in English but our application will keep growing over time so we really need to do this right otherwise it will cost us a lot of time and money to correct that later when we'll have people using our 'API' (I'm calling this an API but I may be wrong about that)
Anyway, we're stuck here, I hope I was clear enough, if not tell me and I'll try again!
Thanks in advance
PD: I posted this in the ASP.NET and Design and Architecture forums, I apologize if this is not ok and you're free to delete one of them.
|
|
|
|
|
_Zorro_ wrote: The problem we're dealing with is that both teams may develop on the same web
pages, controls, business logic etc
First problem is right there.
Those components probably should not be treated the same in terms of Professional Services (PS) (customization for different clients.)
Commonly the business logic will have a standard API, which the PS can either add to or replace. Replacement is an option and one that should probably be avoided. A plug in architecture can enhance the above by assuming that functionality will be replaced while provide a default functionality ONLY if a replacement isn't found.
For the GUI it is often only a replacement, either complete or plugin (but I have almost no GUI experience so other options might exist.)
But regardless I think you need to have an explicit strategy for business objects and a different one for GUI even if it seems like they overlap.
All of that is a design/architecture problem only and not build/install.
For install/build ALWAYS uses the following idiom.
1. Lay down the base product.
2. Lay down the customer (PS) product on top.
|
|
|
|
|
Thank you jschell,
What you’re describing about the BL is more or less what we started.
We made a project where we allow other developers to override the implementation of our functions. If we find that/those DLLs then we use theirs otherwise we use ours.
It works great actually. But the main concern is the UI. We do not want to have to maintain a lot of duplicated (replaced) pages. What we were thinking was to expose some events and let them write their code dynamically. It would be interpreted at runtime.
What do you think about that solution? Do you see any inconvenient I may be not anticipating?
Thanks again.
|
|
|
|
|
_Zorro_ wrote: What do you think about that solution?
Absolute best way to generalize something is to start from existing examples.
Presumably you have such examples.
You can divide them into categories.
1. Those that are always changed (or almost always)
2. Those that are sometimes changed.
3. Those that seldom are.
The first case requires a relook in terms of architecture/design. It could be that the base functionality is just wrong, or that there are easily defined pluggable areas that would make it obvious.
The second case is harder in that it might require a more flexible look or it might just be leave it as it is.
The last case is easist, it must always be written fresh as an overlay.
|
|
|
|
|
Thank you for your answers
|
|
|
|
|
On my organization, we're doing the same thing as you do: Develop a product (core), and at the same time provide customization (integration).
First of all, we have several environments per each customer. Development, Test, and Production. Development environment is for developers, Test for testers and Production for customers. Easy enough!
Plus when we do a deployment in either Test or Prod, we first get the core, and then overlay the changes. And that overlay-ed source is installed in the environment. So the changes doesn't get lost.
We need the Test environment between Dev and Prod because Dev is frequently changing, and not stable enough for testing, and we can't do whatever-we-want in the Prod environment.
For our customization's (integration for you), we have a set of Dev/Test environments per customization project.
No matter how many APIs you develop, your problems will remain there until your two teams develop in the same environment.
|
|
|
|
|
We know that many things in code are possible, but that doesn't mean you have to code something horrendous.
To me, having an option on a property page control the "spawning" of additional property pages (Tabs) is just rediculous (what makes it worse is that it creates an error when repeated or simply trying to use.)
Are there some good design resources or user interface style practices (on the Net or book form) that I can share with my clueless collegue?
Much thanks before I explode in anger.
JJM
|
|
|
|
|
john john mackey wrote: Are there some good design resources or user interface style practices (on the
Net or book form) that I can share with my clueless collegue?
Official Guidelines[^] from Microsoft.
Bastard Programmer from Hell 
|
|
|
|
|
awk! I saw the Microsoft site, but aren't these the same people who created the horrible interfaces that are cited in the "How not to create an interface" links found on the Net?
Yes, the MS site had some good suggestions. Thank you.
JohnJohn
|
|
|
|
|
john john mackey wrote: Yes, the MS site had some good suggestions. Thank you.
My pleasure 
..and yes, there are some good arguments in there.
Bastard Programmer from Hell
|
|
|
|
|
I need a bit of approach advice.
I have 2 forms that have the same custom section of form drawn in each. The controls are drawn according to some data in the database.
At the moment I thought about copying the Code from one form to the other but I am sure there is a better way!
Any pointer for me to read upon ?
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
If the same piece of UI appears on more than 1 form, it would seem prudent to create that part of the UI as a UserControl and host it on both forms. The logic should be encapsulated neatly then.
|
|
|
|
|
potentially a blonde question here but
is it considered better to pass the database data too it rather than getting the user control to query the database?
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
I would have a central repository for the database data. a cache if you like, and just query that from the user control - it's one location for the UC to talk to, and it's easy to implement using a static class.
|
|
|
|
|
As an alternative; create a form that contains the common controls, and inherit both other forms from there.
Making it a UserControl, as already suggested, would be a better idea though
Bastard Programmer from Hell
|
|
|
|
|
Personally, i would go for the inheritance method even thought user control is a great approach.
|
|
|
|
|
John T.Emmatty wrote:
Personally, i would go for the inheritance method
even thought user control is a great approach.
It's an option; but you can use multiple UserControls in different forms - and inherit only from one form at a time.
Bastard Programmer from Hell 
|
|
|
|
|
Why not have a custom control that wil talk to database and render itself accordingly. this can be used on both the forms.
|
|
|
|
|
For simplicity and focus: the whole issue of "multiple undo'redo" is left "off-the-table" here at every level discussed. Also, for simplicity, the idea of a global "restore all settings to default values" is ignored here.
Suppose you have an application that has many (as in over one-hundred) user-configurable settings, and these are easily divided into several "functional areas of related settings."
Very logical to assume you have some overall selector UI/control to choose a focal "functional area:" and, when that area is selected, you present a UI with all the various controls necessary to set the options for that area.
Now let's say you endow each UI for each "functional area" with five "state-changing options" ('Undo' and 'Redo' can be handled by the usual keyboard shortcuts): possibly, three "buttons:" Save, Cancel, Reset
1. Undo / Redo : the usual: reverse/restore the last/previous change in the last control that had focus, and that you changed, in the current area.
2. Reset: which restores all local settings in the area to the state they were in when you first opened up this particular area to modify settings. Possibly confirm required by modal dialog.
3. Cancel: to my mind Cancel and Reset kind of have the same result, although Cancel usually implies a switch in focus to some other mode in the UI. Possibly confirm required by modal dialog.
4. Save: keep mind that "Save" here applies only to the specific area of functionality that is currently presented for settings modification.
The issue now arises, that if the user puts the focus back on the area selector UI, and chooses another area of settings to modify: should it be a requirement that they must choose to 'Save, or 'Cancel ... as the settings UI switches ?
Now, finally, to the more interesting point: the end-user has "moved through" some number of the functional areas, and altered settings, saved them, and now wishes to close the "settings ui."
At that point comes ... to my mind ... an interesting group of possibilities: as the settings UI is "closed:" in which case we'll assume there are two choices: Cancel, and Save.
1. Cancel: at that point what does the application "owe" the user:
a. summary information about which areas of settings have been changed and saved, or changed and not yet saved ? A "super-duper" warning dialog that all changes are going to be ignored ?
2. Save: at that point, if there no "modal exit" from each area of settings is required: and there could be area(s) in which settings have been changed, but not yet saved: should the app present some UI that allows the user to check that these areas of changed settings should be ignored or saved before the settings UI is closed ?
Discussion: obviously implementation of such configuration interfaces can be done with varying "philosophies:" you might think of a continuum from:
1. ultimate laissez-faire: you change a setting in any functional area and its changed for the app right then and there, no Save button required on any functional area UI. Switch to another area, close the settings UI: no worry, your settings are saved.
2. ultimate uber-control-freak ocd: every possible exit from any area of the total UI, from functional areas, to the whole shebang, when any change has been made in a settting: requires the end-user to confirm by modal dialog.
Appreciate your thoughts about what you view as your own "best practice" in this kind of scenario.
thanks, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
Hi Bill,
1.
over one hundred settings is quite a lot. I hope there is a lot of orthogonality in there, so the "mental model" complexity is limited.
2.
I advice to go for the simplest save/cancel/reset/redo/undo stuff that is sufficient for the job.
3.
when settings are grouped somehow, and their changes should be applied per group, rather than individually, I advice against tab pages (which one normally can switch away from at will, leaving multiple dirty pages, most of them out of sight).
4.
my preference goes like this:
- for each "functional unit", provide a separate modal dialog;
- give each dialog only two exit buttons: Save and Cancel; I tend to color them green and red respectively.
- give all controls their initial value; change their backcolor as soon as the user changes their value (so he can see what got saved changed before deciding on save/cancel);
- keep an accurate "modified" flag, and only enable the Save button if some change really has been applied;
- validate the inputs, don't allow the user to save invalid settings.
- optional: provide a way to reset a single control to its initial value;
- optional: provide a way to reset everything in the dialog to its initial value (not essential, user could cancel and open the dialog again).
5.
the above scheme may have two disadvantages:
4a. you can't modify settings of two units simultaneously (if they interact strongly, you might want to be able to do that);
4b. problems arise when functional units and their dialogs start to become hierarchical: when a parent dialog opens a child dialog, which gets closed by clicking Save, what should the parent's Cancel do? are the child's changed settings saved anyway (easy to implement), or is everything canceled? (more logical).
HTH
modified 2-Jan-12 13:19pm.
|
|
|
|
|
Thanks, Luc, for your detailed and thoughtful comments, and ideas, on the various issues and possible solution methods in this "problem space," in which, clearly, there's no "one-size-fits-all" implementation.
One point: it is very easy to restrain the end-user from switching tab-pages in a WinForms TabControl by simply defining a TabControl_Deselecting EventHandler, and setting the 'Cancel property of the TabControlCancelEventArgs argument to 'true.
It is interesting to me to study the massive preferences/configuration facilities in programs like UltraEdit, ReSharper, and Visual Studio.
And, I suppose if there's an "aboriginal" model for setting preferences/configurations across a range of functional areas ... it's the Windows Control Panel (?): of course that is such a diverse collection of all kinds of functionalities, there's hardly what you might have termed "orthogonality" in it !
I think the "point" the implementor chooses along this hypothetical continuum of preferences UI design between "laissez-faire" and "uber control-freak" ... for the degree of user confirmation of change ... has a lot to do with the nature of the application, and its broader context.
Nuclear power plant control comes to mind, at one of the end of the spectrum, and preferences for "Angry Birds" (?) at the other It's easy to imagine one scenario requiring writing logs for every single change of any application preference or setting, and another app that just needs a context menu with, maybe, one or two levels of whatever.
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
The Control Panels approach in Windows is highly orthogonal, as each panel controls a number of settings that is unrelated to the next group. And it follows my suggestions pretty well: one window per group, each window having an OK and a Cancel button, etc. The major deviation is they are separate processes and hence can show their dialog simultaneously.
|
|
|
|
|
Ah, Luc, I see you and I are using the term "orthogonal" in very different ways: to me "orthogonal" means some encapsulating context in which some group of objects, or functionality, are:
1. integrally related
2. enveloped/contained/framed by a consistent "user-interface" for each integrally related "component."
Would you say that a "garbage can" is orthogonal because you can stuff anything in it that will fit it in it ?
Yes, that's an extreme "reductio ad absurdum:" but, to me, the Windows Control Panel, is just a container for a whole bunch of stuff, almost every one of which has a totally different UI, some of the Control Panel Items when opened then lead to even further radically different UI's.
If there's one thing that has characterized Windows from early version right up to 7, it's lack of orthogonality: inconsistency in which some parts of the UI save their configurations, and others don't.
For example: the order in which Date/Size/FileType/FileName are presented in Explorer Windows which may change based on no principle I can discover with the rational mind: or the sudden decision if you open a folder with .MP3 files, or photo files, to present all kinds of possibly not desired Explorer view columns.
Bizarre UI inconsistencies like having a slider control in the View menu to switch between Icon/Detail views.
Multiple UI pathways to configure different areas like Display characteristics.
It's been much too long since I had a Mac to compare with, on these criteria, however.
But, what can you expect from the evolution of dinosaurs ?
Looking back, I wish Apple had acquired Be, not NeXT, but then there would have been no Steve Jobs to restore the company by making it into a mass-media-player and mobile-phone colossus.
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
BillWoodruff wrote: 1. Undo / Redo : the usual
My usual looks like a Memento.
BillWoodruff wrote: 2. Reset: which restores all local settings in the area to the state they were in when you first opened up this particular area to modify settings. Possibly confirm required by modal dialog.
BillWoodruff wrote: 3. Cancel: to my mind Cancel and Reset kind of have the same result, although Cancel usually implies a switch in focus to some other mode in the UI. Possibly confirm required by modal dialog.
Sounds good, even though you should not rely on your own preferences, but on the expectations of your users.
BillWoodruff wrote:
4. Save: keep mind that "Save" here applies only to the specific area of functionality that is currently presented for settings modification.
Your "save" is what other applications call "OK" as confirmation, assuming that you're showing your settings in a modal dialog.
BillWoodruff wrote: The issue now arises, that if the user puts the focus back on the area selector UI, and chooses another area of settings to modify: should it be a requirement that they must choose to 'Save, or 'Cancel ... as the settings UI switches ?
No, only when the settings are dirty.
BillWoodruff wrote: Now, finally, to the more interesting point: the end-user has "moved through" some number of the functional areas, and altered settings, saved them, and now wishes to close the "settings ui."
..he presses "Ok", "Apply" or "Cancel"? I agree that "Reset" might be valuable. And yes, if you're not using a modal UI, than it might sound reasonable to name it "Save".
BillWoodruff wrote: 1. Cancel: at that point what does the application "owe" the user:
a. summary information about which areas of settings have been changed and saved, or changed and not yet saved ? A "super-duper" warning dialog that all changes are going to be ignored ?
When the user exits the form, while there's still dirty. Pop up a MessageBox telling the user that there's unsaved sh*t, asking whether he want's to save them (Yes, No, Cancel). Yes defaults, and you can keep a history of the previous "setting" in your table. That way you'll always be "safe" when the user blindly confirms the dialog
BillWoodruff wrote: 2. Save: at that point, if there no "modal exit" from each area of settings is required: and there could be area(s) in which settings have been changed, but not yet saved: should the app present some UI that allows the user to check that these areas of changed settings should be ignored or saved before the settings UI is closed ?
None of the apps that I know thoes that, not counting installation-packages. I'd go for a "Save all" or "Loose all" option, unless there's some good reason to show a summary.
BillWoodruff wrote: 1. ultimate laissez-faire: you change a setting in any functional area and its changed for the app right then and there, no Save button required on any functional area UI. Switch to another area, close the settings UI: no worry, your settings are saved.
That's a lazy-developers' tactic, that could lead to users resetting a lot of changes, simply because they need to undo the last three changes. It might also lead to accidental changes, where people press a button repeatedly to wake the computer and kill the screensaver.
BillWoodruff wrote: 2. ultimate uber-control-freak ocd: every possible exit from any area of the total UI, from functional areas, to the whole shebang, when any change has been made in a settting: requires the end-user to confirm by modal dialog.
..and piss of your users. Simply, would you like to confirm every step? Would you actually read any dialogs of that application at all?
BillWoodruff wrote: Appreciate your thoughts about what you view as your own "best practice" in this kind of scenario.
Done, hope that it didn't offend to much. Best wishes for coming year
Bastard Programmer from Hell
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
