Business Clients and how they actually think

I just met up with a very business-like client who's the total non-technology savvy person, and I must say it has been a very fruitful experience to understand the thinking of how non-techno people think.

Basically just drawing back on my previous blog, the idea of a User-Role-Centric Solution and Approach to the problem. Apparently it came to very good use as I subtlely veered her into that thinking, or maybe she already is thinking using that approach. Anyway, that's really besides the point. But that approach actually made her able to come up with fantastic ideas for what she actually wants in her business or logic-wise. Note that we were actually talking quite non-technical here and more of what she wants to do, or what service she wants to provide the user. By thinking along that terms, she could come up with quite alot of business processes that she wants implemented, like her Invoice process, her Customer process, and so on.

From my point of view, this is actually quite a good way to draw out what your client actually wants for the solution, and how she wants it done. In my case, I would have never thought about enabling the invoice to be output into an excel file then making it available for printing, nor would I have known about how she wants herself to view the payment reports, nor would I have thought about how she wants to keep her customers by adding some added-value/services to her business, and so on. And she also has a better understanding and quite a clear understanding of how the solution works by us listing down the functionalities of what each type of person can do, without alot of the techy details. The most techy thing would be to describe the process of how the system works. As in, the user enters something, and the information is submitted into the system, and thus the system will inform the admin staff and send back a confirmation email to the user. Something along that lines. Very basic techy stuff. Nothing on like how it actually works.

Of course, the document must have these things available, in a bit more details, but that's for another section. I actually have a Project Guidelines document which I'll put up some time this week for you guys to look at. It's quite interesting. But some things I might want to emphasize. Know your clients, and write your document accordingly. Safest way to do it, think in a business sense. :)

Till next time,
Cheerios.

Project Lamenting and User-Role-Centric Solution

For those of you who know about my new project, I've been so damn busy working on it. This client basically wants me to come up with all the business logic and specifications of what SHE wants, but DOESN'T tell me what SHE wants, so therefore I have to predict and be a fortune-teller to come up with something that SHE'S expecting, because she herself doesn't know what SHE'S wants the solution to do.

Simply fantastic, lamenting on this crappy project. I'm going to charge her for the consultation! Furthermore, I wasn't there during the meeting with the client to dig out information from her, and pick out everything out of her brains.

So anyway, here's what I've been researching and doing for the past few days.

I finally realised when creating a solution, one MUST think about the person using the solution itself. Trying to explain this method to my friend(s), who are in on the same project as me, made me realise the importance of a User-Role-Centric Solution. While coming up with the User-Role profiles, I realised a lot of unseen features appear that's not realised during the so-called "feature-creation" phase, which was done BEFORE creating this User-Role profile. Which was not supposed to be the case. *DEVELOPERS*

Anyway, creating a user-role profile is basically as simple as this. Determine who's going to use the solution. For example, in my case, we came up with 4 user-roles. The "General Person", the "Student", the "Teacher", the "Admin Staff". From this, I think you'll have a rough idea what the type of business this company I'm doing this project for are doing.

The question to ask when figuring out what user-roles there are is simply,
Who will use this solution?

So then, here are a few questions you'll ask yourself about each user-role.
1) Who are the people who falls into this category?
2) What does the person expect to accomplish with this solution?
3) What does the person need to have to use this solution?
4) Is there any problems with the current solution that can be solved with our solution?
5) Is there any forms of information communication between another user-role? What are they?
6) What are the tasks that the person can do with this solution?

Basically these are the few questions that one would ask the client, but apparently there wasn't a chance to do that for my case. Therefore I had to ask myself, and my other friends this question, and see what we can come up with.

In actual fact, we realised that when comparing with our original feature-list module-seperated format, which isn't entirely non-valid and still useable in the proposal under the section "Scope of the Project" and "Solutions Concepts", that we actually came up with more features that we didn't think of in the feature-list, and removed quite a fair bit of features that weren't needed and quite redundant. Which was good, in a sense that now the entire solution was based on "what the person is able to do with the solution", instead of "what this solution can do for the person". There are subtle differences, but when you actually think about it, your entire specification list simply changes and morphs into an almost totally different style. WHICH IS A GOOD THING(tm). So there and then, things start to change.

And I hope you guys also follow this way of thinking, instead of plunging down into feature-list.

Cheerios. Till next time.

Exhausted

Sorry guys. I've been so extremely busy creating my presentation slides and demo on "Generics on the .NET Framework 2.0" and organising the Christmas Party yesterday and playing host and everything, that I'm just totally worn out.

I'll be posting more within the next few days so just to let you guys know I'm still alive and blogging.

StringControl

StringControl, something I wrote last night to handle parsing of text between tags. I'm not too sure whether there's another easier way to do it, but here's what I came up with.

public class StringControl : Control {
  private string m_text;

  public StringControl() {
  }

  public StringControl(string text) {
    m_text = text;
  }

  public string Text {
    get { return m_text; }
    set { m_text = value; }
  }

  protected override void AddParsedSubObject(object obj) {
    if ( obj is LiteralControl ) {
      m_text = ((LiteralControl)obj).Text;
    }
  }
}

Why did I create a simple control like this? It's basically to handle this situation easily.

<sgdn:ModuleItem href="testhref" forumref="testforumref">
  <heading>Testing Heading</heading>
  <text>Testing Text</text>
</sgdn:ModuleItem>

Notice if I wanted to do that way, I needed to create a control to parse the text between <heading> and <text>. The code is something like this.

[ NotifyParentProperty(true), PersistenceMode(PersistenceMode.InnerProperty) ]
public HeadingControl Heading {
  get { return new HeadingControl(m_heading); }
  set { m_heading = value.Text; }
}

[ NotifyParentProperty(true), PersistenceMode(PersistenceMode.InnerProperty) ]
public TextControl Text {
  get { return new TextControl(m_text); }
  set { m_text = value.Text; }
}

So basically I consolidated the logic for both HeadingControl and TextControl into 1 class called StringControl which will parse the inner text of the tags.

Fantastic don't you think? But I'd prefer if there's a better way to do.

Inner Content of a Custom Control

To retrieve the inner content of a custom control, you'll first have to make sure your control does not specify the ParseChildrenAttribute or specifies ParseChildrenAttribute(ChildrenAsProperties = false). Then after that, you can make use of protected void AddParsedSubObject(object obj) method to parse your inner content into a property. For example.

public class MenuItem : Control {
  private string m_href;
  private string m_text;

  public string Text {
    get { return m_text; }
    set { m_text = value; }
  }

  protected override void AddParsedSubObject(object obj) {
    if ( obj is LiteralControl ) {
      Text = ((LiteralControl)obj).Text;
    }
  }
}


But if you want to parse html, I suggest creating your own Templated Control.

Back to coding.

Complex Properties with Inner Property Persistence persisting a Collection property in a User Custom Control using Code Beside Method

Man that's one long name. I'm so excited to blog about this!

Here's the case, I've been trying to learn how to embed custom tags within custom tags. Basically in ColdFusion, a custom tag is the same as a Custom Control. It's much easier to do it in ColdFusion, but that's another story.

So I was actually trying out templated controls, but it turned out it wasn't really what I wanted. Templated Controls are basically almost empty controls that exposes it's structure for you to change accordingly. Which is not what I really want.

Then I came upon something that fits the description. To pass in multiple XML-like "data" into the user custom control. NOTE: USER CUSTOM CONTROL. Very important note there.

Anyway, it's basically called inner property. This is how to create an Inner Property.

// your other methods and whatsoever. I'll skip to the property
[NotifyParentProperty(true), PersistenceMode(PersistenceMode.InnerProperty)]
public void MyClassWithInnerProp MyInnerProp {
  get { .... }
  set { .... }
}

As simple as that. And the html side would be like this.

<mytag:mycontrol runat="server">
  <MyInnerProp />
</mytag:mycontrol>

Basically something like that. Wonderful right? That's exactly what I needed. But wait! What if I needed a collection of the same property? Hell breaks loose. Something along the lines like THIS.

<mytag:mycontrol runat="server">
  <MyInnerProp />
  <MyInnerProp />
  <MyInnerProp />
  <MyInnerProp />
</mytag:mycontrol>

The twist is, to create a collection of properties, you'll have to specify this attribute in your control class. Something like this.

[ParseChildren(true,"MyCollecProp")] // where MyCollecProp is your collection property
public class MyControl : WebControl {
  //blah blah blah
  [NotifyParentProperty(true), PersistenceMode(PersistenceMode.InnerDefaultProperty)]
  public MyCollectPropClass MyCollecProp {
    get { ... }
    set { ... }
  }
}

Ok. A few things to note. PersistenceMode.InnerProperty is now changed to PersistenceMode.InnerDefaultProperty. And you HAVE to specify your default property in the ParseChildren(true, "MyCollecProp").

Here comes the problem. What if I want this collection property in my User Custom Control? How do I do it? I can't put an attribute tag when doing Code Beside. You might be able to do it with Code Behind. Anyway, simply enough, I combine the 2 methods, by creating 1 Inner Property which is a Control which this Control has a Collection Property! WOAH! Fantastic!

Here's the code.

// your other methods and whatsoever. I'll skip to the property
[NotifyParentProperty(true), PersistenceMode(PersistenceMode.InnerProperty)]
public void MyControl MyInnerProp { // Notice the change to MyControl
  pget { .... }
  set { .... }
}

// THIS HAS TO BE IN A CS FILE AND COMPILED IN A DLL THEN ADD THE @ REGISTER TO THE
// PAGES INVOLVED (mainly the User Custom Control and your Page using the control)
[ParseChildren(true,"MyCollecProp")] // where MyCollecProp is your collection property
public class MyControl : WebControl {
  //blah blah blah
  [NotifyParentProperty(true), PersistenceMode(PersistenceMode.InnerDefaultProperty)]
  public MyCollectPropClass MyCollecProp {
    get { ... }
    set { ... }
  }
}

And the html would be something like this.

<mytag:MyUserControl runat="server">
  <MyInnerProp>
    <MyCollecProp />
    <MyCollecProp />
    <MyCollecProp />
    <MyCollecProp />
  </MyInnerProp>
</mytag:MyUserControl>

Of course, I'm assuming you already know how to write your collection class and naturally your data class.

Wonderful idea huh!! Look at it get implemented at SgDotNet website!

I'm not too sure whether any of you guys understood, if there's any questions, just post in the comments and I'll reply them.

w00t rocks!

First Attempt to deploy

Well, I've deployed the initial stages of the website on to the development site for SgDotNet. Here's the link. http://dev.sgdotnet.org. There are quite alot more visual issues to be fixed, but generally that's how it will look.

I'm still trying to get everything else up and working.

Tired. Cheers.