Wow, I didn't realize that we don't do browser detection (I haven't done much with watchdog yet). That kind of information is key in designing your site... Why spend time working on IE5/Mac bugs when less than 0.2% of your users use it? How else would you know that unless you track that info?! Anyway, Dries is in charge of this, is he not? How can we see some action on this? Chris On Wed, 19 Jan 2005 00:43:41 +0100, Steven Wittens <steven@acko.net> wrote:

Chris Messina wrote:

Most of these blocks already exist in Drupal as separate stats/watchdog pages with more information on them. Most of them just come down to doing the right query and passing the formatted results to theme('table'). The ones we don't have are browser and platform detection. Also, I suspect the 'search strings' box actually displays the strings extracted from referrers such as Google and friends, which Drupal's search messages are searches performed using Drupal's own search.

Steven Wittens

Op woensdag 19 januari 2005 02:14, schreef Moshe Weitzman:
> 1: noone has contributed code to do so. This can be done outside of core
> if anyone cares to work on it.
I once started the xstatistics.module for this exact purpose:
* To keep Drupals stats clean and simple.
* And to have a place where those exact stats show up: It featured 
  ** amount of nodes
  ** amount of comments
  ** amount of node views
  ** etc

It looked very similar to what you showed there. 

Chris, David, I suggest you get the dust of that module, or get someone to do 
it for you, if you want this sort of features. 


-- 
Regards,
 Bèr
--
 [ Bèr Kessels | Drupal services www.webschuur.com ]

Implementing stuff like browser detection can be annoying, as you need to keep its database up to date to the latest browser releases. The best solution would be to find a good reference set that is easy to import and kept up-to-date. Though I agree with Moshe that Drupal's stats module should mainly be for Drupal-related stats. Webalizer tells me the

I'll +1 to this. The current stats are great for a quickie eyeball of today's stats, but if I really want something "professional", I'll just depend on my weekly analog stuff, which never gets deleted. -- Morbus Iff ( the power of grayskull compels you! ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

It's not so much that I'm worried about writing browser detection into the theme layer as I am catering to browsers which my audience doesn't use. Check out this post for more information: <snip> Last month, I had posed the question: When can we hide from IE5/Win?. In retrospect, I probably should've titled the entry: When can I hide from IE5/Win?. Because, as others have rightfully pointed out, *what matters most are the statistics from your own site, not others.* </snip> http://www.simplebits.com/notebook/2005/01/12/clarification.html So the broader topic here, which is important to me and my audience, is about giving the kind of wider statistical information to the user that might normally get stuck in third-party stats packages. You may have these packages and know how to use them, but a gross majority of Drupal users a) won't have access or the means to see these stats b) won't be able to install these packages (ie hosted installs) c) won't want to go to a separate place to find out how their website is performing. With all due respect, I understand where you guys are coming from and saying that Drupal should report on Drupal, but I do think that the watchdog module is somewhat limited to a more general audience that may not have access to third party solution (for whatever reason). Therefore, if I can find someone to help code, I will gladly help reform the current watchdog module into something a little more robust, nimble and Tuftesque. Any takers? Chris On Wed, 19 Jan 2005 13:54:38 +1100, Gordon Heydon <gordon@heydon.com.au> wrote:

Hello,

* Morbus Iff (morbus@disobey.com) wrote:

...

...

Implementing stuff like browser detection can be annoying, as you need to keep its database up to date to the latest browser releases. The best solution would be to find a good reference set that is easy to import and kept up-to-date. Though I agree with Moshe that Drupal's stats module should mainly be for Drupal-related stats. Webalizer tells me the

I'll +1 to this. The current stats are great for a quickie eyeball of today's stats, but if I really want something "professional", I'll just depend on my weekly analog stuff, which never gets deleted.

I think that the one thing that core should do is for watchdog to capture additional information such as the browser identifcation string, and just store it in the watchdog file.

Then some bright spark can write a contribution module that formats the stats to get this information.

As for browser detection, drupal should not do this at all. If they theme is that complex, then you can do browser detection in your theme to get around the problems. -- Gordon Heydon <gordon@heydon.com.au>

Op woensdag 19 januari 2005 11:46, schreef Gabor Hojtsy:

Chris, it would be nice to keep the watchdog/statistics module simple, and only provide the means for contrib modules to extend their functionality.

Chris, For exactly this reason I started the xstatistics: to eXtend the statistics :) However, Drupals reports can use a lot of cleaning up, but that would result in *less* statistics by default, instead of *more* -- Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

weeks from now! I've seen a lot of usability ideas/talks lately, but so far, only very few materialized and made it into CVS. I truly hope that

Yes, there have been talks, threads and mockups but I did not see an agreement. So I can not help in realizing, 'cos it is not clear what should be realized. Think of me as a simple foot soldier: just show me the target, and it will be demolished er.... I mean coded. (And I will take care of code style, sorry Steven.)

If its up to me, there wont be a lot of improvemnts in Core in 4.6. The reason is simeple: WE need guidelines we all agree upon *above all*. I know talk is silver code is gold. But that is *the exact* reason drupal is so messy right now: Everyone opesn his PHP editor, codes away, focussing on speed, efficency and nice code. Which is good. But coders nearly always seem to forget to look at themeability and useability. Simply because its not in their line of interest (often)

I disagree. It is great that you want to lead a team to write HIG for Drupal. I hope you succceed in publishing those. But to stop development until these HIG are published is silly. The HIG are vaporware, just like all the promised patches to add "ADODB layer" or "comments as nodes" or "groupware" or "webdav". Drupal is not "so messy" IMO. It is so clean. Have you looked at other similar projects? I suppose this is a matter of taste. Coders who want to contribute to core don't just just focus on "speed, efficiency, and nice code" if they want to get their patch accepted. You have to get everything exactly right. You have to use a form group around multiple related controls, you have to use css in a sparse manner, you have to use a sortable table when data might want to be sorted. And so on. Skip any of those steps (and many more) and the patch languishes.

Because of all this, we really need talk, agreements and ideas. Not code. So if you want useabiltiy code into 4.6, youve got a huge pile of work to do.

Talk is fine, but I discourage getting in the way of the code until HIG is non vaporware.

Bèr Kessels wrote:

Maybe now, yes. But that does not count for contributions. And worse: it does not count for all those silly things that are still in core from long ago. Just look at the node-submission page: it is messy, and one cannot reaaly change it, at least not in a theme. Those are things I am talking about, when talking about the mess. But theres much more.

The idea that guidelines will help us /fix/ Drupal's existing UIs and interaction design is an illusion. That said, it will help us catch obvious violations and will be a tremendous help for many. It's much needed to ensure consistency across modules (especially for contributed modules) so +1 on that. I own two books on website usability, and spent a fair amount of time digging usability articles online. Having read these books and articles -- combined with user feedback on drupal.org -- helps me understand and pin-points Drupal's usability pains. I have learned a lot the past two years, I have been on a mission to help create usability-awareness and last but not least, I have spent a fair amount of time implementing usability improvements. However, it doesn't necessarily empower me to take apart the existing UIs and to redesign them. Often, I had to consult Michael Angelas and Kristjan Janssen. Furthermore, there is _no_ reason not to fix some of the mess in Drupal 4.6. The lack of guidelines didn't stop me from improving the statistics and throttle module in HEAD, nor did it stop Neil from improving the block administration, or Steven from drastically improving the search results. In fact, I doubt that the above improvements (many are all about good "interaction design" not "interface design") would automagically get dictated by good guidelines. There is plenty of stuff we can improve (eg. menu configuration, node submission form, comment moderation, grouping settings) without the need for setting HIGs in stone. For one, nothing stops us from making substantial improvements to the node submission page or to better organize the settings pages. I'm sure HIGs will help us refine such improvements. -- Dries Buytaert :: http://www.buytaert.net/

Op woensdag 19 januari 2005 13:49, schreef Moshe Weitzman:

...

If its up to me, there wont be a lot of improvemnts in Core in 4.6. The reason is simeple: WE need guidelines we all agree upon *above all*. I know talk is silver code is gold. But that is *the exact* reason drupal is so messy right now: Everyone opesn his PHP editor, codes away, focussing on speed, efficency and nice code. Which is good. But coders nearly always seem to forget to look at themeability and useability. Simply because its not in their line of interest (often)

I disagree.

It is great that you want to lead a team to write HIG for Drupal. I hope you succceed in publishing those. But to stop development until these HIG are published is silly. The HIG are vaporware, just like all the promised patches to add "ADODB layer" or "comments as nodes" or "groupware" or "webdav".

It is indeed still vapourware, but vapurware that starts too look promising. :)

Drupal is not "so messy" IMO. It is so clean. Have you looked at other similar projects? I suppose this is a matter of taste.

We should never, ever say: "we are better then others, thus we can stop improving". Thats sillyness. And if i compare drupal to some closed source CMSes i've seen, or to blogger.com or other /services/ we have a very, very long road to go, useability-wise.

Coders who want to contribute to core don't just just focus on "speed, efficiency, and nice code" if they want to get their patch accepted. You have to get everything exactly right. You have to use a form group around multiple related controls, you have to use css in a sparse manner, you have to use a sortable table when data might want to be sorted. And so on. Skip any of those steps (and many more) and the patch languishes.

Maybe now, yes. But that does not count for contributions. And worse: it does not count for all those silly things that are still in core from long ago. J

...

Because of all this, we really need talk, agreements and ideas. Not code. So if you want useabiltiy code into 4.6, youve got a huge pile of work to do.

Talk is fine, but I discourage getting in the way of the code until HIG is non vaporware.

I never meant this as "Dont code untill i say so". I meant it as "Please rather help us getting this streight for once and all, insteasd of improving tidbits here and there" So are any people interested in helping? Ive got some interresting (IMO) stuff for review. -- Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

Op woensdag 19 januari 2005 17:51, schreef Steven Wittens:

I also think that your current view of the average Drupal developer is a bit silly: most of the patches committed lately have involved at least some UI developments and improvements. In fact, I've noticed that aside from performance patches, the code structure is very rarely brought up in patch review, and the UI is the main discussion point.

Totally agreed. There have been a lot of improvements lately. But none of them are structural. All these improvements take one small part and improve it. Most of the time (thats good) towards more consistancy. But no-one seems to really know what this consistancy is. My scope is wider /and/ deeper. I want to go both ways: A document (needs not to be long, especially if we are consistent we need to deescribve only fewer cases) but also better APIs. So to summarise: These node mockups by chris are great, but really very far away, IMO. For sure someone could code them. But my point is: we are not yett ready for such code, because that same person would then need to re-code every case for every role, with every nodeapi-extension in mind. No, my point is: we need to agree first on how these screens in general should behave and look (the wider scope) and then re-code the nodeapi calls to suit them (deeper scope). Its good. We are really very far down the road of having good UIs, but we still have along way to go too. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

So how did you get this installed and working? It is a simple setup? Chris On Wed, 19 Jan 2005 01:06:58 +0000, Paul Byrne <paul@leafish.co.uk> wrote:

Strange coincidence... I've just installed this on one of my drupal sites (babylonleaf.com). At the moment it runs on a different domain, and I have a module enabled to simply call the appropriate file from ShortStat (inc.stats.php) to do the logging. Its a very nice stats script, especially for those customers/clients who find scripts like Webalizer, Urchin, Analog, AWStats etc either too confusing or just plain overkill.

On Thu, Jan 20, 2005 at 11:53:27AM +0000, Paul Byrne wrote:

Chris Messina wrote:

...

...

Strange coincidence... I've just installed this on one of my drupal sites (babylonleaf.com).

...

So how did you get this installed and working? It is a simple setup?

Yep. I had no problems installing it (separate to my drupal install) on a subdomain. The readme is pretty comprehensive, and I had no problems.

Once the script was set up, to get it working with my site I have just added the lines:

/** * support for ShortStat - should be moved into module */ @include_once("/my/path/to/inc.stats.php");

into index.php. Its a quick hack for now, and I mean to create a simple module to achieve this rather than hack a line into a core file.

Put it in includes/conf.php or sites/.../settings.php depending on what Drupal version you are using. This is acceptible. A module would be even better, but perhaps a bit overkill. And yes, drupal rewrites the urls. You should pull up .htaccess and the Apache manual if you want to figure it out. Or use the full url, which is not rewritten because Drupal sees that something else is there that it should not interfere with. -Neil http://civicspacelabs.org/ http://delocalizedham.com/

Paul Byrne wrote:

So its got to be down to referrer, as entering the URL into the address bar takes me to the correct page. However, how does drupal pick up the link? Something must be going on client-side, as far as I can see.

Stupid, stupid, stupid... never thought to check the ShortStat script itself... // Redirect to homepage if linked directly if (!empty($_SERVER['HTTP_REFERER'])) { header("Location:http://$_SERVER[SERVER_NAME]"); } (in index.php). Sorry for wasting everyone's time... ;) P -- paul byrne <paul@leafish.co.uk> web monkey <http://www.leafish.co.uk/>