This project is read-only.

Requirements for the Client

Apr 3, 2008 at 11:51 AM
Edited Apr 3, 2008 at 1:59 PM
Here is my draft set of requriements for the client.

1. Obtaining the client
1.1 Simple web download
1.2 Shipped via Micosoft Updates
1.3 Download linked from key forum pages.
1.4 Promoted via MSDN, TechNet channels
1.5 Open Source Licensing of some variety

2. Installation of the client
2.1 Create so it does not require setup (i.e. for install/run from USB)
2.2 Run in LUA mode and should not trigger UAC
2.3 Provide full customisation of installation location(s)
2.4 Multiple database options (SQL Compact, SQL Express, SQL)
2.5 Installation defaults over-ridable via GPO

3. The Client In Operation
3.1 File size should be small
3.2 Storage of Images are end user controllable
3.3 Posts can be composed, sent and received in pure text or HTML - user definable
3.4 Viewing of messages can be user controlled
3.5 Articles must be indidually downloadable
3.6 Threads must be individually downloadable
3.7 Posts shoudl be capable of being created off line and sent when on-line.
3.8 Article retention time user definablble (by article, thread or group)
3.9 Group reset - to reset the articles available in a given group.
3.10 Send/Receive of articles from the MS forum store should be async and run in the bacground (as a service?).
3.10 There should be a view into the service (curent status, stats on articles processes, sizes processed, etc. Pleae provide great stats!
3.11 Background service should be "kickable" - as in "please send/receive now.
3.12 Ability to set speed of service up/download, both how often it shoudl check to send/receive, but also band width limits, integrated into Vista QOS.

4. Composing Articles/Replies
4.1 Spell Check built in (like Live Writer).
4.2 Multiple levels of Undo (like Live Writer)
4.3 Signature features - different signatures for different forums, plus the ability to select sig per article.
4.4 Cross-post to multiple forums from a single post, with user/policy defined upper limites.
4.5 Ability to reply directly to sender via SMTP or similar
4.6 Ability to forward to third parties via SMTP or similiar
4.7 Ability to BCC replies or forwards via SMPT or similar
4.8 Ability to add an attachment (e.g. a document)
4.9 Rich editing capabilites including but not limited to copy, paste, and selectively move text in an answer or post.
4.10 Ability cancel a post that you sent.
4.11 Ability to edited and replace a previous post
4.12 Enable 3rd party cancels facility
4.13 Enable post to be digitally signed (eg. with PGP or other terse digital signature).
4.13 Support all RFC based NNTP Headers for future interop
4.14 Support for emoticons - to render in both text and "rich-text" mode
4.15 Ability to support creating and reading rich text (HTML) directly side by side with a rich editor (similar to Live Writer).

5. Retreiving Articles
5.1 Block any sender's name - any articles by that email address (or perhaps based on some regular expression around the FROM: or simlar header)
5.2 Block any sender's domain
5.3 Block HTML
5.4 Block content, including subject or body
5.5 Support content types that are blocked via setting or policy (include mime types).
5.6 Choose which groups we want to see and/or load
5.7 Ability to "suspend" subscription to a group/forum. This would keep all current messages, and possibly post replies, but not download new articles from that forum.
5.6 Choose how many messages we want to download for a given download session.
5.7 Choose which servers we want to connect to and provide global server coverage (as MSDN/Technet etc do today with web downloads).
5.8 Expose all non-RFC standards based header items (i.e. any customised MS header information) as X- NNTP header types for interop..
5.9 Blocking behaviour (sender, domain, etc) set globally or per group

6. Reading articles
6.1 Flag or mark any message or thread - flag as important, normal, unimportant, kill. Also flag for "watch" for replies to either an entire thread or just to article (and all replies genereated from there).
6.2 Ignore any message or thread - either not view or drop to unimportant
6.3 Watch any message or thread and promote in view when replies are received
6.4 See only replies to our own posts
6.5 Mark and download only those messages we want to see.
6.6 Get notification when a reply to a "watched" thread/articles arrive.
6.7 See messages in a tree view, with watched threads promoted (and watched threads with replies promoted higher still). Similar to turnpike

7. Search Capabilities
7.1 Must be able to seeach based on (at least):
a. Messages from
b. Messages to
c. Any word or phrase in the subject
d. Any word or phrase in the body
e. Any word or phrase in the header
f. Handle regular expressions in all searching

8. Security
8.1 Connection with the servers must be via well known ports (e.g 80, 443).
8.2 User must be able to connect securely (eg SSL, TLS)
8.3 Client must be able to store user Password

9. Administration and Control
9.1 Key security settings controllable via GPO
9.2 User Settings Controllable via GPO
9.3 Enable data store location to be specified at install
9.4 Enable data store location to be moved post install
9.5 Enable data store to be backed up and restored
9.6 Integrate with VSS for backup
9.7 Provide mechanism to compress data store(s)

10. Desktop/System Integration
10.1 Should provide a system tray icon - which can flash for a new reply.
10.2 Provide PowerShell Cmdlets and provider for accessing local data store(s)
Apr 17, 2008 at 6:04 PM
Okay Thomas, now that I published my "official" draft I went through and looked at where we mapped up and where we didn't. For anything that I think I either missed, can't do, or don't want to do, I put a response here. You actually caught a couple great ideas that slipped past me and I'll get added to the main document.

1. Obtaining the client
1.2 Shipped via Micosoft Updates - We can look into this deeper, but I have a feeling this will be beyond what is possible with this project unfortunately. I’m glad you brought it up though, it would have slipped past me otherwise.
2. Installation of the client
2.2 Run in LUA mode and should not trigger UAC – I forgot this in the requirements, that’s a really good one I’ll have to add, it’s such an easy one to say “duh we should do that”, but it’s certainly not a gimme in all cases, so it needs to be explicit. Good one!
2.4 Multiple database options (SQL Compact, SQL Express, SQL) – This is in the requirements, but I don’t know how feasible it’s going to be to architect, just thought I’d mention that. 
2.5 Installation defaults over-ridable via GPO – I’m going to sound dumb but what’s GPO? Group Policy Orchestration?

3. The Client In Operation
3.2 Storage of Images are end user controllable – I think you hit something that I missed here. I thought the forums would strip out any embedding of images in the HTML but I was wrong! We’ll definitely need a user configurable option for how to save / cache images in messages. It could actually get very tricky.
3.5 Articles must be indidually downloadable – I’m not sure there’s a difference between articles and threads for us on the forums.
3.8 Article retention time user definablble (by article, thread or group) – I think I have this, but I may be missing what I think you’re asking for. You want the “auto purge” of local messages based on time I think right?
3.9 Group reset - to reset the articles available in a given group. – I think I missed this one but it should be added.
3.10 There should be a view into the service (curent status, stats on articles processes, sizes processed, etc. Please provide great stats! Another one I hadn’t thought about before, but we should consider.
3.12 Ability to set speed of service up/download, both how often it shoudl check to send/receive, but also band width limits, integrated into Vista QOS. – I have no idea if we’ll be able to tackle this any time soon. Do any newsreaders really do this today?

4. Composing Articles/Replies
4.1 Spell Check built in (like Live Writer).
4.4 Cross-post to multiple forums from a single post, with user/policy defined upper limites. – This one is a policy issue, but we generally don’t allow cross posting. We leverage the expertise of the moderators to get the question into the forum best suited for it if it was asked in the wrong place.
4.5 Ability to reply directly to sender via SMTP or similar – Since we don’t use e-mail as your identity, we use Live ID, we don’t have a way to connect users directly together through the system. This is a general forums issue, and I think once we have private messages solved for the entire stack we’ll be able to add it to the client.
4.6 Ability to forward to third parties via SMTP or similar – I believe we’ll be hooking in to the system registered e-mail client for forwarding / e-mail type features. It’s on the list, we’ll want to review the scenario to make sure it works.
4.8 Ability to add an attachment (e.g. a document) – It’s in there for when the server supports it, today on forums we do not have attachment capabilities.
4.10 Ability cancel a post that you sent. – Deleting posts falls under “moderator” functions (even though this one has implications for the original poster). We’re still working out how we’re going to handle that general class of issues and allow for elegant resolution of conflicts.
4.11 Ability to edited and replace a previous post – Editing is a similar scenario as delete in terms of working up the rules around how it works.
4.12 Enable 3rd party cancels facility – This is covered by the moderator features.
4.13 Enable post to be digitally signed (eg. with PGP or other terse digital signature). – Are you envisioning that the signature is a part of the content of the message? I’m not sure this fits in with the forums model, but I can certainly be convinced otherwise!
4.13 Support all RFC based NNTP Headers for future interop – This one is out of scope for what we’re doing.
4.14 Support for emoticons - to render in both text and "rich-text" mode – I’ve got in some items around emoticons, although we’re going to have to do some deeper work on exactly what we do with them, it all depends on what the forums server does to the text representation of them (replaces them with links to images or interprets them realtime).

5. Retreiving Articles
5.1 Block any sender's name - any articles by that email address (or perhaps based on some regular expression around the FROM: or simlar header) – We have from user, but not e-mail address because of the Live ID.
5.2 Block any sender's domain – Same as above, we don’t have visibility into what domain a Live ID is associated with so there’s no field to block on.
5.4 Block content, including subject or body – Is block different than filter?
5.5 Support content types that are blocked via setting or policy (include mime types). – Forum posts don’t generally have mime types embedded as far as I know, we’ll have to look at this one closer.
5.7 Ability to "suspend" subscription to a group/forum. This would keep all current messages, and possibly post replies, but not download new articles from that forum. – I should make sure this is in there.
5.7 Choose which servers we want to connect to and provide global server coverage (as MSDN/Technet etc do today with web downloads). – The forums run from a single server bank so I’m not sure if this is relevant for a first release, however, we do want to build the tool to be flexible and account for other forums servers so this may make it in at some point.
5.8 Expose all non-RFC standards based header items (i.e. any customised MS header information) as X- NNTP header types for interop.. – This probably won’t happen, sorry.

6. Reading articles
6.1 Flag or mark any message or thread - flag as important, normal, unimportant, kill. Also flag for "watch" for replies to either an entire thread or just to article (and all replies genereated from there). – I have flagging for important and watch lists, is there something special about flagging as unimportant? What’s the use case for that one?

7. Search Capabilities
7.1 Must be able to seeach based on (at least):
a. Messages from – I think I may have missed a and b here.
b. Messages to
f. Handle regular expressions in all searching – This one I’m going to need to work with you to figure out how big a need this is. I put it in but have gotten push back from the dev team.

8. Security
8.1 Connection with the servers must be via well known ports (e.g 80, 443). – I didn’t make this explicit, but we should find out what port the forums server is listening on!
8.2 User must be able to connect securely (eg SSL, TLS) – We may have to work with the forums team to enable this.

9. Administration and Control
9.1 Key security settings controllable via GPO – I hadn’t really thought about policy configuration options. We should figure out where in the priority list this sits. I like the idea, I just hadn’t thought about it before and I don’t know how hard it is to do.
9.2 User Settings Controllable via GPO – Same as above.
9.6 Integrate with VSS for backup – Interesting… Hadn’t considered any backup integration scenarios beyond making the data file movable, copyable.
9.7 Provide mechanism to compress data store(s) – Also hadn’t thought about this one, we’ll have to see what options make sense, this could either be very simple, or get very complicated fast.

10. Desktop/System Integration
10.1 Should provide a system tray icon - which can flash for a new reply. – I didn’t specify this in the UI, but one of my favorite old school mail readers could minimize and be in the system tray only. Would you want that, or would you want it in both the system tray and in the task bar?
10.2 Provide PowerShell Cmdlets and provider for accessing local data store(s) – Another one I didn’t think about but sounds doable at some point.
Apr 20, 2008 at 3:12 AM
tfl: Great list. I don't know if I agree with all of the requirements (and I'll point out if I strongly disagree with something), but it's definitely pretty comprehensive.

Jeremy: I was the one who gave you a pretty rough time when you were presenting with Charlie Calvert at the MVP summit (I believe it was you), just to give you some background.

Here are my comments on the overall list:

1.2 Shipped via Micosoft Updates - My expectation is that this will not be done, although it would be nice in the event that there are updates to the application. I think that if Windows Update can not be used, and it is a .NET app, then use Click Once, or the Application Updater Block in the Enterprise Library.

2.1 Create so it does not require setup (i.e. for install/run from USB) - I don't mind an app that is not stand alone. To be honest, I'm not the type to have to carry certain apps around with me at all times. Also, in the event that the app is NOT installed on a local machine, there is always the web-based interface. If you want the app installed on the local machine, then do so. If you are just need a quick way to bang out a few posts on a machine where it's not installed, I think that the web-based interface is the way to go (it's not the best solution, but there is a backup in the event the app is not installed).

2.4 Multiple database options (SQL Compact, SQL Express, SQL) - This is really an implementation option, IMO, and I agree with Jeremy that this might not be feasible from an architecture standpoint. However, my suggestion later might enable this (I'll explain this further down).

3.3 Posts can be composed, sent and received in pure text or HTML - user definable - I think that in addition to this, there needs to be a way to apply predefined styles (as well as user-created styles) of some sort. It doesn't have to be HTML, IMO (I think that's an implementation issue, personally). Right now, a "code" style stands out the most. It would mean that a means to identify certain keywords would be needed (so that we can get syntax highlighting for a language like, C#, for example).

3.8 Article retention time user definablble (by article, thread or group) - I think it is important to realize that a user might want to save an article forever, as well. Don't force me to purge if I don't have to.

3.12 Ability to set speed of service up/download, both how often it shoudl check to send/receive, but also band width limits, integrated into Vista QOS. - I think the set of data here is typically going to be small, I personally would NOT emphasize the need for this.

4.5 Ability to reply directly to sender via SMTP or similar
4.6 Ability to forward to third parties via SMTP or similiar
4.7 Ability to BCC replies or forwards via SMPT or similar - I don't know that this is typically the culture in the forums. In NNTP newsgroups, it is, and that's what the clients supported, but I would want full integration with Outlook if they are going to do this, but it doesn't make sense to me to have this right now.

4.14 Support for emoticons - to render in both text and "rich-text" mode – I REALLY don't need emoticons. Devote the energy to something else.

5.6 Choose which groups we want to see and/or load - Something I would REALLY like to see is to have multiple views on different forum groups open at the same time (possibly even multiple views on the same group with different filter/ordering criteria). If you AREN'T going to give me this, then MAKE SURE I CAN HAVE MORE THAN ONE INSTANCE OF THE APP OPEN AT A TIME!!!

6.1 Flag or mark any message or thread - flag as important, normal, unimportant, kill. Also flag for "watch" for replies to either an entire thread or just to article (and all replies genereated from there). - I mentioned this at the summit, that I'd really like to see when someone responds to something I have posted (this is really support for 6.4, now that I see it).

7f. Handle regular expressions in all searching - Come on, is it THAT hard? There are readily available regex parsers out there (and a very good one that MS provides in the .NET framework as well) which can be used. I'm not saying that I know the architecture well enough to say it would be difficult, but I do agree that this is important.

8.3 Client must be able to store user Password - Bad idea in my opinion, but make sure I can shut it OFF!

9.3 Enable data store location to be specified at install
9.4 Enable data store location to be moved post install
9.5 Enable data store to be backed up and restored - I think that 9.3 and 9.4 aren't really important if you have the ability to specify in the program a place to backup/restore to (9.5). As long as you can do that, and indicate where the data store is (again, I don't need to know the format, but make it easy for me to move data around, and move it around in a single file if I need to).

10.1 Should provide a system tray icon - which can flash for a new reply. - I'd definitely want this to be SHUT OFF. Provide an option to make sure I can disable the tray icon. I HATE tray icons, as do a lot of other people. Something related to this is a vista sidebar gadget. Consider allowing access to the store programatically (so I can write one) or provide a gadget yourself where I can follow a particular group or groups.

As mentioned in my comments on 2.4, I think that a large amount of extensibility would be a very good idea. Firefox (which I do not use, but I definitely respect the design decision) was very extensible from the start, and I think that it's a great app model for something like this. If you had extensibility points for everything (or most things), then I think the community will respond to fill in the holes. Extensibilty points can be used for handling the data store (you tell the extensibility point what to store, what to retrieve, etc, etc), the rendering of the content, applying styling to the content, posting mechanisms, retrieval mechanisms, etc, etc.
Apr 21, 2008 at 1:59 AM
I forgot to mention, something that is really, really important to me is to have a threaded view, unlike the current web-based implementation, which is stack based.
Jul 2, 2008 at 11:21 AM
After having read the requirements-doc and the discussion about requested requirements here, I'd say that all functionality that *I* would need on a daily basis is included here. I'd consider myself as a newsgroup user with only a small knowledge about the new Forums (although I've looked into them and posted a few answers there).

If you guys would deliver a Forums client with that kind of functionality, it would be more than just "usable" for me.

cheers,

Florian

P.S.: "GPO" is actually Group Policy Object - but Jeremy you got "Group Policy" already right.