Am I alone in detesting the user interface of Sharepoint? Over the last 6 years, I've worked on many projects at 3 different multinational corps and all of them started by using Sharepoint as the project document repository, but in every single instance, people ended up just emailing documents around as it was a whole lot easier and quicker to work with Outlook than Sharepoint.
Does anyone have a well configured Sharepoint that normal users used actively and enjoyed working with?
Discussion on:
View:
Show:
Isn't that why you should deploy Office 2007? You are then able to save and share directly from SharePoint document libraries without using the web front end.
Alternatively, you can also map the document libraries so they function like a network shared folders.
Alternatively, you can also map the document libraries so they function like a network shared folders.
That's exactly why we went with SharePoint.
I took various manager level people, who were scrolling pages and pages of outlook screens as some kind of "file management system", to a single SharePoint Document library. It was a no brainer and is used readily. I agree, most companies don't have the process-minded people in place to make their rollouts a success. They think "just throw it in SharePoint and it will work".
I took various manager level people, who were scrolling pages and pages of outlook screens as some kind of "file management system", to a single SharePoint Document library. It was a no brainer and is used readily. I agree, most companies don't have the process-minded people in place to make their rollouts a success. They think "just throw it in SharePoint and it will work".
You must install one of the versions of Office 2007 that support SharePoint integration to have a seemless SharePoint experience.
- ProPlus, Ultimate, Enterprise
- ProPlus, Ultimate, Enterprise
Well, not fighting it, since I can't find any opponents.
My users prefer to dump everything in shared folders, creating sub folders as needed. SharePoint has received some favorable acceptance in our other facility, the one that's more project oriented than this one. Here there has been as close to no interest as possible. vorpahl mentioned the importance of the roll-out, but no one here seems to have a use for it. Combine that with no easy way to migrate the massive amount of information in our old document management system (DocsOpen) over to SP, and the reluctance of my users to having to search two storage systems.
Addressing k.stafferton's point, I'm not seeing the advantages of using Office 07. Maybe I'm not integrating the apps with SP as effectively as possible. I can't figure out how to access files stored in SP from an Office app. Also, I recall a way to create a 'Network Place', but I remember it as being a lot harder than just mapping a network drive in a login script.
My users prefer to dump everything in shared folders, creating sub folders as needed. SharePoint has received some favorable acceptance in our other facility, the one that's more project oriented than this one. Here there has been as close to no interest as possible. vorpahl mentioned the importance of the roll-out, but no one here seems to have a use for it. Combine that with no easy way to migrate the massive amount of information in our old document management system (DocsOpen) over to SP, and the reluctance of my users to having to search two storage systems.
Addressing k.stafferton's point, I'm not seeing the advantages of using Office 07. Maybe I'm not integrating the apps with SP as effectively as possible. I can't figure out how to access files stored in SP from an Office app. Also, I recall a way to create a 'Network Place', but I remember it as being a lot harder than just mapping a network drive in a login script.
Well, relatively long, anyway.
We use it in IT for projects. When a project starts, we create a site, then as the system is implemented, the site is transitioned over to a support site. We keepp all of the documents from the contract negotiations and the project implementation, including all of the manuals, then we keep the procedures related to that system there. When the product is replaced, the website is archived.
We also use the workflow capabilities that are a more recent addition. For example, we have a new doctor on staff, and there are a lot of people who have to know when the credentials are verified and what date the Doc is starting. There's a checklist, and depending on what step is completed, certain notices go out to certain people. That's helped the process.
In addition, the Policies and Procedures are all online. The only problem is enforcing the use of Metadata. Our Sharepoint admin has been trying to get people to use that intelligently for a while now.
We use it in IT for projects. When a project starts, we create a site, then as the system is implemented, the site is transitioned over to a support site. We keepp all of the documents from the contract negotiations and the project implementation, including all of the manuals, then we keep the procedures related to that system there. When the product is replaced, the website is archived.
We also use the workflow capabilities that are a more recent addition. For example, we have a new doctor on staff, and there are a lot of people who have to know when the credentials are verified and what date the Doc is starting. There's a checklist, and depending on what step is completed, certain notices go out to certain people. That's helped the process.
In addition, the Policies and Procedures are all online. The only problem is enforcing the use of Metadata. Our Sharepoint admin has been trying to get people to use that intelligently for a while now.
My main question would be:
Why go with SharePoint then? or are you stuc in having to support the product. Use folder shares, encrpyption software and VPN's where needed for remote users. Limit access and viewability by the locks at the AD level and start with that. Office2007 doesn't offer anything new for SharePoint ease-of-use.
I'd also consider some of the "secure" online storage access vendors, of which there are hundreds if not thousands.
Why go with SharePoint then? or are you stuc in having to support the product. Use folder shares, encrpyption software and VPN's where needed for remote users. Limit access and viewability by the locks at the AD level and start with that. Office2007 doesn't offer anything new for SharePoint ease-of-use.
I'd also consider some of the "secure" online storage access vendors, of which there are hundreds if not thousands.
It wasn't my call. Its successful implementation at our other site has my superiors wondering why the users at my site aren't don't get it. By extension, there are questions about my ability to recognize its value and 'sell' it to them. (Hell, I have questions about how to best use it. I've never seen a similar system and don't recognize when it would be the appropriate tool.)
Our DocsOpen installation is over a decade old, unsupported, and must be replaced. SharePoint is the logical candidate, but my users won't consider it until the existing data in DocsOpen is migrated. I've seen no actions on this front, only an agreement that it needs to be done. Such an operation is over my head.
There's also the question of SP's capabilities being oversold to the users. I was excluded from the presentations that were held over a year before roll-out. Users have told me that the final implementation has fallen well short of the promises and potential present in those meetings. It leaves an understandable bad taste in their mouths.
Part of the implementation is an emphasis on content management by the users. Frankly, they don't have the skills, and I wouldn't expect them to; content management isn't their job. This is accompanied by the usual lack of training. It was rolled out with a 'Here it is! Have at it!" approach. This may have worked at the other site, with a much higher percentage of engineers, project managers, propeller heads, and other types who enjoy playing with new technologies, but not here.
Our DocsOpen installation is over a decade old, unsupported, and must be replaced. SharePoint is the logical candidate, but my users won't consider it until the existing data in DocsOpen is migrated. I've seen no actions on this front, only an agreement that it needs to be done. Such an operation is over my head.
There's also the question of SP's capabilities being oversold to the users. I was excluded from the presentations that were held over a year before roll-out. Users have told me that the final implementation has fallen well short of the promises and potential present in those meetings. It leaves an understandable bad taste in their mouths.
Part of the implementation is an emphasis on content management by the users. Frankly, they don't have the skills, and I wouldn't expect them to; content management isn't their job. This is accompanied by the usual lack of training. It was rolled out with a 'Here it is! Have at it!" approach. This may have worked at the other site, with a much higher percentage of engineers, project managers, propeller heads, and other types who enjoy playing with new technologies, but not here.
It's a useful tool for us. We have people who don't have, and don't need to have, calendars, outlook, network shares, etc...
This is one place to aggregate information such as policies and procedures, announcements, training materials, team collaboration sites, the previously mentioned workflows, etc..
Will every business like it or use it? Absolutely not, but it works for us, and solved many more problems than it creates.
This is one place to aggregate information such as policies and procedures, announcements, training materials, team collaboration sites, the previously mentioned workflows, etc..
Will every business like it or use it? Absolutely not, but it works for us, and solved many more problems than it creates.
Something else to learn about a product I'm still trying to figure out. Beautiful, just beautiful.
What does this afterthought bring to the party? Some additional functionality that MS would have included in the first place if they weren't in a rush to get to market?
Sorry, my cynicism is running high this afternoon, especially where this product is concerned.
What does this afterthought bring to the party? Some additional functionality that MS would have included in the first place if they weren't in a rush to get to market?
Sorry, my cynicism is running high this afternoon, especially where this product is concerned.
SharePoint Designer is Microsoft's replacement for FrontPage. It's a far better product though. And you don't have to learn it - it's only needed if you want to make customisations that can't be done using the web interface or CSS. I recommend avoiding these if possible anyway.
It would have to be. I tried FrontPage a couple of times and could never get anywhere.
Yeah, I never liked FrontPage. I can't say I ever spent long enough with it to have given it a fair go, but it just didn't feel right to me. I've always used Dreamweaver, and from the limited time I've spent with SharePoint Designer, it seems to be pretty similar.
I played with both FP and DW for a simple personal site. They were far more tool than I needed, like having a full wood shop when all I needed was to drive a couple of nails. I never dove very deep into either one.
Two more failed experiments in Microsoft's attempt to dominate the world of software. Fortunately Google is too big for them to buy.
Apparently they're selling enough of it to continue development, sales, support, etc.
On what are you basing the claim that SharePoint is a failed product? It's definitely not a product for eveyone, but it's great at what it does. Overwhelming I've found posts by people that use the product to be positive. The only negatives I tend to hear are related to poor implementations, trying to bend it to do things it wasn't intended to do, or where users were not involved.
I'm far from convinced it was an attempt to "dominate the world of software" either. Indications are that Microsoft saw this as a niche little product... something nice to throw in with Server for free. I think they were surprised at how popular it became. It is now a billion dollar product for MS, and is set to be the fastest growing Microsoft product to $2 billion.
I'm far from convinced it was an attempt to "dominate the world of software" either. Indications are that Microsoft saw this as a niche little product... something nice to throw in with Server for free. I think they were surprised at how popular it became. It is now a billion dollar product for MS, and is set to be the fastest growing Microsoft product to $2 billion.
We started implementing SP2007 back in 2007 as a simple replacement for the SPS2003 Intranet site everyone hated. It took about two years for users to start seeing the value of the new SharePoint system. Over time, we developed various features and deployed numerous web applications to address corporate issues discovered during process analysis across the enterprise. We are slowly migrating appropriate documentation and processes to SharePoint in a multi-year phased approach that doesn't force the technology on everyone. Our SharePoint champions have really taken hold of the technology and now manage their own department sites. One department went entirely paperless using workflows and links to documents in their site. Consequently, they are saving over $75,000/year in gained productivity and reduced expenses. We are seeing a steady climb in acceptance now and have numerous projects to extend the functionality. People simply need to see the value in action, something that is provided by leaders with vision.
None of this would have happened if the technology couldn't support the effort or if the right people weren't on the job to support and implement the technology in appropriate ways. It is a team effort that takes patience, planning, and pro-actively applying the technology to solve business problems and addressing user needs.
With 2010, we anticipate another increase in momentum from other segments of our business that have seen limited functionality in 2007 for their tasks.
None of this would have happened if the technology couldn't support the effort or if the right people weren't on the job to support and implement the technology in appropriate ways. It is a team effort that takes patience, planning, and pro-actively applying the technology to solve business problems and addressing user needs.
With 2010, we anticipate another increase in momentum from other segments of our business that have seen limited functionality in 2007 for their tasks.
GUI: It's a similar approach to the rest of windows...if you don't like it, you'll need to go elsewhere. Having said that, it's one of the most flexible and effective interfaces ever created by MS. I think there are 3 points you should consider - First, any document management system has some overhead, if you don?t want those features, turn off versioning & checkin/checkout and any workstreams associated with the document library. Second, it?s easy enough for anyone to configure, with a little time investment, try one of the 10-minute books (MS SharePoint 20xx in 10 minutes) to get very specific directions on changing the configuration. Last, you can turn to SharePoint Designer, which has virtually unlimited ability to tweak & configure sites?which is one of the reasons most IT shops limit it?s use.
Site Sprawl (#2): duh. But site creation is one of the most powerful and useful features for collaboration, such as workspace sites. We?ve been using Meeting workspace sites for sometime, and they are enormously effective ways to improve meetings. The downside is that they create a subsite?right from Outlook when you create a meeting appointment. Surely you?re not suggesting IT get involved in creating these? Or are you just talking about main sites?
Site Sprawl (#2): duh. But site creation is one of the most powerful and useful features for collaboration, such as workspace sites. We?ve been using Meeting workspace sites for sometime, and they are enormously effective ways to improve meetings. The downside is that they create a subsite?right from Outlook when you create a meeting appointment. Surely you?re not suggesting IT get involved in creating these? Or are you just talking about main sites?
IMHO - SharePoint was developed to promote the need for paid support by M$ professionals only. There is extremely limited support for this product outside of M$ and for the incredible amount of mgmt. and maintenance, not to mention the renaissance programming skills required as well as a DBA - this is the "beast" of Microsoft.
I'm in favor of the KISS system when it comes to sharing - which is to say, that sometimes you have to live with differing systems that DO and CAN integrate - which work just fine, don't require 5 extra people on staff, and are relatively headache free.
Thumbs down to SharePoint - deploying it any fashion no matter the version. You simply don't "have to use it!"
T Bostwick
SystemsAdmin/Analyst/Development
I'm in favor of the KISS system when it comes to sharing - which is to say, that sometimes you have to live with differing systems that DO and CAN integrate - which work just fine, don't require 5 extra people on staff, and are relatively headache free.
Thumbs down to SharePoint - deploying it any fashion no matter the version. You simply don't "have to use it!"
T Bostwick
SystemsAdmin/Analyst/Development
What other viable alternative exists? ie. What else is there on the market that can provide the same level of functionality?
He already answered that right there in his post... you keep it simple by having multiple different products, then spend your time programming kludges to get the differing programs to interoperate. Then, of course, you re-program when the next version of any of your programs is released. Writing code specific to multiple programs to get them to talk is so much easier than having the apparant 5 IT staff you need to use SharePoint's edit-what-you-see interface.
A lot of good points have been brought out in this article.
In my view - SharePoint is a lot more than just another pretty file management system (not that pretty by default if you ask me). Being able to create and deploy custom workflows using windows workflow foundation with as many branches and conditions as you like; creating websites-groups-permissions-workflows-document libraries automatically at runtime; deploying custom C# web controls as web parts - these things can have a lot of power. There is already a sound architecture in place that you can extend without re-inventing the wheel. In a lot of cases, 80% of what users want to do can be done with SharePoint "out of the box" (but that's pretty boring...) so users can do quite a lot (including basic workflows) on their own without necessarily having a developer at their disposal.
One of the big challenges with deploying SharePoint for me is software development lifecycle and configuration management. Since SharePoint stores changes to pages in the database, that makes it a real challenge when it comes to versioning control of the site configuration itself. How do you keep your development environment in sync with your staging/testing environments and still be in sync with production?
Migration can be a real nightmare. Just because you made backups of your development or test site doesn't mean that you can then restore them to an installation on another server. That would take all the fun out of it.
The command line tools for backing up a website as such have limitations - size constraints being among them. Yet - because the page and list changes are stored in the database, you can't just over-write what you have in production with what you just developed. I guess you could but you'd have to 1) know which content database(s) your site is using 2) back them up before deployment 3) restore after deployment 4) pray a lot (and hope there aren't any major list structure changes that are going to blow up your stored data and break work flows).
If the only thing you are changing are your deployed custom webparts - that isn't quite as ugly...it's a matter of deploying your dlls, publishing the dlls to the global assembly cache, making changes to your config files, etc.
Security is another thing to consider. By default - the basic SharePoint groups/role definitions are 'read', 'contribute', and 'full control'. The problem with that though is that all of these definitions allow everyone to see everything -- so if you want to present content based on the user's role - you have to jump through a few flaming hoops.
The learning curve has been pretty steep for me - I've had to learn everything I've learned on my own...and I still consider myself to be fairly new to this type of development. Sometimes I wonder which is less painful...SharePoint - or whacking myself on the head repeatedly with a brick. I just wonder if anyone else has experience with these things and has recommendations for configuration control and migration for incremental releases.
In my view - SharePoint is a lot more than just another pretty file management system (not that pretty by default if you ask me). Being able to create and deploy custom workflows using windows workflow foundation with as many branches and conditions as you like; creating websites-groups-permissions-workflows-document libraries automatically at runtime; deploying custom C# web controls as web parts - these things can have a lot of power. There is already a sound architecture in place that you can extend without re-inventing the wheel. In a lot of cases, 80% of what users want to do can be done with SharePoint "out of the box" (but that's pretty boring...) so users can do quite a lot (including basic workflows) on their own without necessarily having a developer at their disposal.
One of the big challenges with deploying SharePoint for me is software development lifecycle and configuration management. Since SharePoint stores changes to pages in the database, that makes it a real challenge when it comes to versioning control of the site configuration itself. How do you keep your development environment in sync with your staging/testing environments and still be in sync with production?
Migration can be a real nightmare. Just because you made backups of your development or test site doesn't mean that you can then restore them to an installation on another server. That would take all the fun out of it.
The command line tools for backing up a website as such have limitations - size constraints being among them. Yet - because the page and list changes are stored in the database, you can't just over-write what you have in production with what you just developed. I guess you could but you'd have to 1) know which content database(s) your site is using 2) back them up before deployment 3) restore after deployment 4) pray a lot (and hope there aren't any major list structure changes that are going to blow up your stored data and break work flows).
If the only thing you are changing are your deployed custom webparts - that isn't quite as ugly...it's a matter of deploying your dlls, publishing the dlls to the global assembly cache, making changes to your config files, etc.
Security is another thing to consider. By default - the basic SharePoint groups/role definitions are 'read', 'contribute', and 'full control'. The problem with that though is that all of these definitions allow everyone to see everything -- so if you want to present content based on the user's role - you have to jump through a few flaming hoops.
The learning curve has been pretty steep for me - I've had to learn everything I've learned on my own...and I still consider myself to be fairly new to this type of development. Sometimes I wonder which is less painful...SharePoint - or whacking myself on the head repeatedly with a brick. I just wonder if anyone else has experience with these things and has recommendations for configuration control and migration for incremental releases.
It's the nature of intranet sites to become larger and larger and unless they are culled regularly end users start getting older 'mis-information'. One solution is EScreenz that points end users to specific (hopefully newer) targets within SharePoint or any intranet site for that matter.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
