The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Public Information System :: Any Suggestions?

I have been tasked with creating a company-wide information system to be displayed on screens attached to remote PCs dotted around my place of work.

We already have an intranet which I've put together over the last 5 years so I have a very good handle Web technologies, specifically ASP with a small amount of ASP.NET experience.

This Information System (IS - I'll drop the "Public" otherwise the acronym would be PIS!) will rotate (not sure if randomly, sequentially or both) through a number of different content. Some static news items (company-wide and department-specific) entered into a simple CMS by departmental content editors, some specific RSS feed content, some company stats and figures updated dynamically from various computer systems within the company, and possibly other, unthoughtof content.

I was thinking about creating a sort of mini, hands-off intranet, maybe using ASP.NET with plug-in modules to handle the different content sources/management that maybe write to a central "playlist" of content that the "player" randonly picks from or cycles through?

The remote PCs (many will be physically inaccessible) will run a maximized, full-screen browser and point to the "player" page and maybe contain an area argument in the URL (e.g. /is/player.aspx?area=Accounts).

I suspect that I may need a background command line app to run constantly that refreshes, updates and removes content in the playlist by cycling through each "plug-in" requesting its content and adding it to the playlist.

Does this sound like a reasonable solution?

Are there any applications or frameworks out there that will already do all of this without so much investment of my time as a full-blown, bespoke solution would take?

I appreciate any comments and suggestions you could give.
charley Farley
Thursday, October 12, 2006
I'm not sure those remote machines will be able to install the latest versions of your browser components without manual intervention. Instead of doing it inside a maximized browser, a simple executable that calls home (within your intranet) would seem adequate to me.
Thursday, October 12, 2006

thanks for your comments.

the remote machines WILL be accessible by me via Remote Desktop or VNC or something else. Primarily I was just making the point that users won't be sat at the keyboard and be able to move a mouse around like a conventional intranet page.

The monitors (big screen TFTs) will be high up on a wall somewhere out of sight of the PCs (long monitor leads) and we're hoping they'll be visible from a fair distance away (big fonts!).
charley Farley
Thursday, October 12, 2006
I would just write a webservice to provide your content, then create a windows forms client application to rotate through the content. You'll have a lot easier time coding in windows forms, and greater control over when stuff happens.
Chris McKenzie Send private email
Thursday, October 12, 2006
Central webserver generating pages for each department - by pulling in feeds from other sources.
Kiosk mode browser on each PC set to refresh the page from the server every n seconds.
Server can cache static html pages if the number of PCs is high and the rate of change of incoming data is low.

You can then use any machines for the clients so long as they can run a browser, even diskless linux set-top boxes.
XP can even run the background as a fullscreen browser if you turn off the toolbar, recycle bin etc.
Martin Send private email
Thursday, October 12, 2006
Opera is particularly nice for remote-controlling, you can send commands to the running process to produce refreshes (amongst other things).

Saying that, your app seems a perfect candidate for liberal sprinklings of javascript to poll the server for new content, and even new components, so you'd never have to touch it.
G Jones
Thursday, October 12, 2006
The simplest design would be completely RSS based. You develop the software that generates the various feeds on a central server: your static news item feeds (company-wide and department-specific), your company stats and figures, even alerts, announcements, video podcasts and other feeds. And all those remote PCs just have specialized RSS readers screen savers that control order and priority of display items. You can subscribe your remote PCs to the relevant feeds based on their location/department etc.

You can try the free firstobject News Reader (no config or install) which has a screen saver (Menu -> Show Screen Saver) to illustrate the idea.

You would want a bigger font though and possibly the ability to display multimedia content.
Ben Bryant
Thursday, October 12, 2006
I might be wrong (saw a demo years ago), but I thought Microsoft Share Point (and Share Point Portal) was made for a situation like this.
Thursday, October 12, 2006
Thanks again for all your very helpful comments.

Doug, Sharepoint might well be able to do it but there will probably be a steep learning curve and nine times out of ten, big frameworks like this don't quite do exactly what you want that a small, lightweight, home-grown system can.

Ben, I like the idea of making it all RSS-based. Certainly something that would make adding new content sources easier.

This raises a "sub-question".

Because the purpose of all the "clients" is simply to display content on a rotational basis (some clients sequentially, some client randomly) I didn't really want each client to individually poll every content source, make a decision about what to display and then display it. The client's sole job is simply to display content.

Therefore, I would have thought some kind of "content server" should exist that has a bunch of content queued that it can send to each client when requested? Then each content provider is only polled by this content server rather than n clients. This makes sense?

I have cases that make me wonder how best for a content server to keep track of which item to show each requesting client, how to ensure the client doesn't have to wait for content, how to ensure that all the messages are displayed but offer an option of weighting certain messages so they appear more often or having IMPORTANT messages that override all the others "FIRE WARNING" for example?

Has anyone any experience of developing a similar queued content distribution system? This is what makes me think I'll need a background process (content server) that is regularly polling the content providers for "what can I show" and inserting them into a master playlist table? The server also needs to be "clever" enough that when "the next" piece of content is requested by a client it displays the next item, possibly area specific, possibly sequential, maybe random (again dependent upon departmental location) so some kind of session will need to be maintained so a client's progress through the queued content can be tracked.
Charley Farley
Friday, October 13, 2006
Yes, that's nice. It is a little more work to run everything from the content server, but it fits the broadcast model nicely. It is like you are running a bunch of channels and all you do is tell your remote PCs which channel to tune into. It is also more efficient if your remote PCs are just listeners (i.e. daemons), rather than polling, particularly on the alert feed which they would be polling every few seconds in the RSS design.

One small question that came to mind regardless of your design is how you will use remote desktop if you want a regular application to run on those remote screens. Generally when you RD into a box, you take the screen over and all that remote monitor displays is a blank login screen.
Friday, October 13, 2006

Aha! You have a good point regarding the Remote Desktop "issue". I hadn't considered that, but of course you're right, once I close my RD session, the remote PC will display the login screen. Given this, I'll have to install something like UltraVNC which leaves the PC running whatever it was running when you leave the session. Thanks for saving me from an embarassing "oversight" though!

Because it's so much easier for me to use a plain browser at the client end rather than a "listening" client application because all I'm displaying is HTML (unless coding an app to "listen" or "tune in to a channel" is trivial?) and because there will be only a handful of remote machines (less than 10) I was planning on having the content server iterate through each content provider, building up and ultimately writing a playlist.xml file (RSS or some simple bespoke XML format). Each client would then use AJAX to load the items from the XML file, filter for the appropriate departmental content, prioritise and place the content in an array. Then, iterate through this array, displaying each content for the given amount of time (present in the playlist.xml file for each content item). Once the client-side content array had been iterated, another AJAX call would be made to bring in the next content and so on. I might even be tempted to "double buffer" the content read so the client still has items to display while it's reading and parsing in the next playlist.

Meanwhile, the content server would be refreshing the playlist.xml as needed.

I'm sure there are better technical solutions, hence my post here for some advice?
Charley Farley
Friday, October 13, 2006
I like the idea of multiple "channels."  I think that if you had a query string for which channel to tune into, you could use that for building the page that they client sees.  That way the client browser would not have to sort out which information to show based on department, you would do that all on the server.

Something like http://internalSite/channels?id=lobby or id=sales.  That way the server controls the content for each channel, and it is easier to add new channels.  The browser just needs the address to hit.
Friday, October 20, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz